Ankündung Softwareupdate

[OneAndOnlySon]

Habt ihr schon mal über die mysql-Konfiguration als Ursache nachgedacht? Für Parameter-Änderungen dürfte es aber jetzt auch zu spät sein. Was sagt denn das Slow Query Log?

[Elrond]

Die mysql Konfiguration ist eigentlich ausreichend dimensioniert. Der Server hat 4 GB RAM und die Datenbank ist myisam. Delayed Key Write ist bereits eingeschaltet. Die Posting Tabelle hat ca. 1.5 Mio Eintraege mit rund 2.1 GByte Daten und 1.3 GByte Indices.

 

Hier mal der relevante Part, ich bin froh ueber eine zweite Meinung.

 

key_buffer			  = 512M
max_allowed_packet	  = 384M
thread_stack			= 256K
max_connections		 = 600 
table_cache			 = 32k 
sort_buffer_size		= 16M 
read_buffer_size		= 8M  
myisam_sort_buffer_size = 1024M
thread_cache			= 64   
wait_timeout			= 60   
interactive_timeout	 = 300  
open-files-limit		= 65534
myisam_max_sort_file_size = 8G
tmp_table_size		  = 2G
max_heap_table_size	 = 2G
myisam-recover		  = BACKUP,FORCE
query_cache_limit	   = 4M
query_cache_size		= 32M

 

Die Config ist auf

 

- Queries moeglichst aus dem Cache beantworten

- maximale Anzahl gleichzeitiger Verbindung

- bloss kein "Repair with Keycache" riskieren

- keine tmp_tables auf Platte

 

ausgelegt.

 

Im Slow Log tauchen bei einer Grenze von 5 Sekunden keine Slow Queries auf und auch keine Abfragen ohne Index Unterstuetzung.

bearbeitet 5. April 2011 von Elrond

[asia]

Was ist IPS?

[Elrond]

Invision Power Services, der Hersteller der Software.

[OneAndOnlySon]

Ich glaube nicht, dass es am mysql-Server liegt. Die Konfiguration schaut soweit gut aus. Man könnte den key_buffer noch höher drehen aber bei mysql bin ich mit kurzfristigen Konfigurationsänderungen eher vorsichtig.

 

Wahrscheinlicher finde ich, dass die Software zu viele Zeilen fetcht und den Speicher nicht wieder frei gibt. Dafür würde sprechen, wenn die Server-Load entsprechend nach oben geht. Wie läuft denn die Konvertierung? Werden die alten Daten gefetcht, dann in der SW konvertiert und in eine zweite Datenbank geschrieben oder bleibt alles innerhalb einer Datenbank? Weißt du, ob die SW die Konvertierung vornimmt oder der SQL-Query? Letzteres ist wahrscheinlich schneller. Aber wenn IPS das Problem von der SW weg schiebt, kannst du eh nicht viel machen.

[asia]

Invision Power Services, der Hersteller der Software.

Aha. Die Meldung ist auch schon wieder verschwunden...

[Elrond]

Ich wuerde davon ausgehen, dass der Key Buffer keinen Einfluss auf die Performance bei der Konvertierung hat, weil jedes Posting nur einmal angefasst wird und vorher ohnehin nicht im Key Cache lag.

 

Die Konvertierung laeuft so, dass die 250 Postings aus der Datenbank selektieren (mit einem SELECT mit Limit und einem Left Join), in der Software konvertieren und jedes Posting einzeln per UPDATE wieder in die Datenbank zurueckschreiben. Danach wieder 250 Postings usw. Der Memory Leak tritt nur dann auf, wenn wirklich konvertiert wird, dann verliert er pro 250 Postings rund 100 KByte.

 

Habe testweise schonmal den FULLTEXT Index ueber die Postings ausgeschaltet um die Vermutung zu ueberpruefen, dass das UPDATE nicht teuer ist, sondern die mannigfaltigen Indices zu aktualisieren das Problem ist. Das hat aber keinen Einfluss.

[OneAndOnlySon]

Die Konvertierung laeuft so, dass die 250 Postings aus der Datenbank selektieren (mit einem SELECT mit Limit und einem Left Join), in der Software konvertieren und jedes Posting einzeln per UPDATE wieder in die Datenbank zurueckschreiben. Danach wieder 250 Postings usw. Der Memory Leak tritt nur dann auf, wenn wirklich konvertiert wird, dann verliert er pro 250 Postings rund 100 KByte.

PHP? Ich kenne aus einer ähnlichen Migration das gleiche Phänomen. Die einfachste Lösung ist wahrscheinlich, pro Durchlauf des Migrationsskripts nur 10.000-50.000 Postings zu konvertieren. Auf diese Art machen wir auch recht umfangreiche Migrationen mit über 5 Mio. Zeilen von einer DB in eine andere.

[Elrond]

Genau, das ist auch mein Ansatz. Aber da man den Konverter nicht parametrisieren kann, muss ich daneben sitzen *ARGH*

[OneAndOnlySon]

Genau, das ist auch mein Ansatz. Aber da man den Konverter nicht parametrisieren kann, muss ich daneben sitzen *ARGH*

Elrond-Job-Queue 2.0

[Elrond]

So, gleich gehts los.

[Chrysologus]

So, gleich gehts los.

 

Dann verabschieden wir uns mal vom Forum in seiner alten Form..

[Elrond]

Schnief!