Smalltalk Guten Morgen, Guten Tag, Guten Abend Kaffeeklatsch
#176596
geschrieben 20. Juli 2016 - 20:38
@HolgerN: Nö, aber kann mir auch nicht wirklich vorstellen dass die was bringen. Der Austauschbehälter muss ja schon riesig sein um die Luft aus einem, sagen wir mal 15m" Raum, abkühlen zu können.
Das kann man jetzt nicht wirklich vergleichen, aber mein 400l. Becken kühlt kein Stück wenn das Wasser 20 Grad hat, sondern hat nach 36-48 St. die Raumtemperatuir angenommen. Sprich ca. 30 Grad
Anzeige
#176597
geschrieben 20. Juli 2016 - 20:54
Na mal abwarten.
#176598
geschrieben 20. Juli 2016 - 21:13
Zitat (Holger_N: 20. Juli 2016 - 19:47)
Ich antworte da mit meiner eigenen Antwort drauf:
Zitat (Samstag: 20. Juli 2016 - 19:06)
Das ist nämlich der Nachteil bei den "Verdunsteranlagen". Selbst wenn sie groß genug dimensioniert sind, um den Raum 2, 3° abzukühlen, so erhöhen sie auch die Luftfeuchtigkeit um einige Prozent. Man gewinnt also genau gar nichts.
Dieser Beitrag wurde von Samstag bearbeitet: 20. Juli 2016 - 21:13
#176599
geschrieben 20. Juli 2016 - 21:21
#176600
geschrieben 20. Juli 2016 - 21:25
Daher empfindet man ja einen schwülen heißen Tag auch wesentlich unangenehmer als einen trockenen heißen Tag, auch wenn beide Tage 35° hatten.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#176601
geschrieben 20. Juli 2016 - 21:33
#176602
geschrieben 20. Juli 2016 - 21:38
Zitat (Holger_N: 20. Juli 2016 - 18:39)
Ist hier ein Anti-SQL-Injection-Wortfilter drin. Ich hatte nämlich »Datenbankwörter« im Text, weil ich geschrieben hatte, dass ich peinlicherweise nach zwei oder drei Jahren erst das mit dem pripär und exekjut statt kweri verstanden habe.
Wenn das der ist wo ich grad drauf geantwortet hab dann nicht.
Was anderes re: DBMS hab ich aber nicht gesichtet.
#176603
geschrieben 20. Juli 2016 - 21:56
Zitat (Holger_N: 20. Juli 2016 - 21:33)
Und dabei Erdbeeren essen.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#176604
geschrieben 20. Juli 2016 - 22:33
Q: How many fucks did Ralph give today?
#176605
geschrieben 20. Juli 2016 - 22:52
Zitat (RalphS: 20. Juli 2016 - 21:38)
Was anderes re: DBMS hab ich aber nicht gesichtet.
Nee ich hatte hier im Smalltalk erwähnt, dass ich das mit dem prepare endlich verstanden habe. Nur so allgemein und der Beitrag ist nun weg. Das Andere hab ich schon gesehen, Danke nochmal, hat gut funktioniert und genau wie ich es bei der Problemstellung schon erahnte. 3 Tage hat mein Skript geschuftet, also nicht am Stück aber ich hab immer 5000 oder 10000 Datensätze durchgerattert und 10.000 haben immer so 30 bis 40 Minuten gedauert und dann gibts einen blöden Befehl und der macht das komplett in wenigen Minuten.
#176606
geschrieben 20. Juli 2016 - 23:49
Das schlimmste was ich hatte war eine SQLite-Datenbank, ca 2G groß, ca 1.8M Datensätze, wo Anfragen > 1 Minute gedauert haben. Schema durchgesehen, mit EXPLAIN die Abfragen durchgeschaut, paar Indices erstellt wo nötig und hey presto, Sekundensache.
- Halte es für MÖGLICH daß bei Dir das prepare() dazwischenfunkt. Das macht ja üblicherweise per-Datensatz. Wenn Du also mit prepare() Millionen Zeilen einfügst, dann muß er wirklich JEDE Zeile hernehmen, schreiben, warten bis sie auf Disk ist (wegen ACID) und dann die nächste und so weiter.
- Das sieht mir nach PDO aus was Du da treibst. Daher: in PDO gibt's direkt PDO::beginTransaction() und PDO::Commit() (glaub ich hießen die, müßtest nochmal bei php.net nachschauen). Damit das Ganze kapseln und den ganzen Vorgang in eine Transaktion stecken. Dann wird der gesamte Vorgang als Ganzes behandelt und die Chose geht um viele Prozente schneller.
... ähm... oder läuft das DBMS auf Deiner Fritzbox? Schau auch mal in die Performancedaten rein, was das Teil so treibt bei IMPORTs. Ich geh jetzt von unnormaler Diskaktivität aus, was da bremst; aber wenn die CPU bei 146% rumtackert und der RAM schon die weiße Flagge gehißt hat, dann weißt Du was Du nachzurüsten hast.
- TLDR: Für 1 Million Datensätze sind Suchen innerhalb einer Minute zu erwarten und - sinngemäß - ein komplettes Refresh aller Datensätze ebenfalls. Wenn Du nicht grad mit Deinem PHP-Script Mist verzapft hast (passiert mir jedenfalls immer mal; einmal for() schleife ne Zeile zu spät geschlossen und die INSERTs nahmen kein Ende) dann solltest Du unbedingt schauen wo das Problem ist, denn "normal" ist das so definitiv nicht.
- Und falls Du Linux oder sowas verwenden solltest, hoffe ich doch mal dringend daß Dein dbdir nicht auf einer ntfs-Partiton liegt.
Dieser Beitrag wurde von RalphS bearbeitet: 20. Juli 2016 - 23:57
#176607
geschrieben 21. Juli 2016 - 18:34
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#176608
geschrieben 21. Juli 2016 - 18:58
Ich habe jetzt eine Abfrage nach Benutzer mit Zeit zwischen x und y gemacht, da stand dann am Ende »22110 rows in set (4.36 sec)« gedauert hat es aber zwei Minuten. Die Ausgabe dauert einfach nur so lange. Und mit Tage meine ich ja nicht, dass die Abfrage Tage lief. Ich hatte mit LIMIT gearbeitet, um einfach zu gucken, wie lange dauert es 1000, 5000 oder 10000 Datensätze durchzuackern. Und da habe ich Montag 300000 Datensätze gemacht und Dienstag auch und Mittwoch den Rest und dann kamen 3 Tage raus. Es wäre natürlich auch an einem gegangen.
#176609
geschrieben 21. Juli 2016 - 19:02
Zitat (DK2000: 13. Juni 2016 - 08:12)
Viel zu lange...
Zitat (Demonia: 13. Juni 2016 - 21:06)
Viel zu viel. Überdosis Real Life würd ich sagen
Namd zusammen.
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#176610
geschrieben 21. Juli 2016 - 19:12
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.