mysql führt zu Server-Ueberlastung

D

dandelion

Aktives Mitglied
Hallo,

Ich betreibe eine Website mit Suchfunktion; es handelt sich um einen Root-Server
(bei Hosteurope, HE L,Dell PE 750, SuSE 9.1, PIV 2,8 GHz/1MB, 1024MB RAM, PHP Version 4.3.4), habe eine mysql-Datenbank mit > 200'000 Sätzen (FULLTEXT-Search, mysql Version 4.0.18 ), ca. 3000 Users pro Tag.

Und nun zum Problem: Die Antwortzeiten sind des öfteren inakzeptabel; eine Suchanfrage dauert
manchmal ein paar Sekunden, manchmal sogar ein paar Minuten und manchmal funktionieren
gar keine Suchanfragen mehr (--> can't connect to database).

Die Datenbank-Tables sind indexiert, ich glaube nicht, dass ich die Zugriffs-Statements noch optimieren könnte. Ich vermute (hoffe...) , man kann mySQL aber noch optimieren, es gibt ja
mit dem Befehl 'Show Status' Dutzende von Variablen, an denen man wahrscheinlich 'herumschrauben' kann. Kennt sich jemand damit aus ? Kann man ev. Caches vergrössern ? Ich kenne mich da leider überhaupt nicht aus.

Wäre toll, wenn ich durch einen kleinen Eingriff die Zugriffszeiten verkürzen könnte.

Danke, Philipp

P.S. Ich erlaube mir, hier die 'show status' variablen aufzulisten:


Aborted_clients 55
Aborted_connects 33
Bytes_received 77772995
Bytes_sent 3739625320
Com_admin_commands 121
Com_alter_table 0
Com_analyze 0
Com_backup_table 0
Com_begin 372
Com_change_db 105755
Com_change_master 0
Com_check 0
Com_commit 372
Com_create_db 0
Com_create_function 0
Com_create_index 0
Com_create_table 80
Com_delete 165
Com_delete_multi 0
Com_drop_db 0
Com_drop_function 0
Com_drop_index 0
Com_drop_table 80
Com_flush 19
Com_grant 0
Com_ha_close 0
Com_ha_open 0
Com_ha_read 0
Com_insert 36558
Com_insert_select 1167
Com_kill 0
Com_load 0
Com_load_master_data 0
Com_load_master_table 0
Com_lock_tables 45133
Com_optimize 20
Com_purge 0
Com_rename_table 0
Com_repair 105
Com_replace 37
Com_replace_select 2
Com_reset 0
Com_restore_table 0
Com_revoke 0
Com_rollback 0
Com_savepoint 0
Com_select 269305
Com_set_option 102
Com_show_binlog_events 0
Com_show_binlogs 0
Com_show_create 102
Com_show_databases 5
Com_show_fields 278
Com_show_grants 0
Com_show_keys 0
Com_show_logs 2
Com_show_master_status 0
Com_show_new_master 0
Com_show_open_tables 0
Com_show_processlist 30
Com_show_slave_hosts 0
Com_show_slave_status 0
Com_show_status 7
Com_show_innodb_status 0
Com_show_tables 422
Com_show_variables 5
Com_slave_start 0
Com_slave_stop 0
Com_truncate 6
Com_unlock_tables 52358
Com_update 149827
Connections 76094
Created_tmp_disk_tables 73718
Created_tmp_tables 118885
Created_tmp_files 796
Delayed_insert_threads 0
Delayed_writes 0
Delayed_errors 0
Flush_commands 1
Handler_commit 0
Handler_delete 41190
Handler_read_first 44073
Handler_read_key 1625839
Handler_read_next 120459703
Handler_read_prev 0
Handler_read_rnd 4887438
Handler_read_rnd_next 20211483
Handler_rollback 0
Handler_update 179504
Handler_write 18082161
Key_blocks_used 15586
Key_read_requests 789139887
Key_reads 284035
Key_write_requests 19025107
Key_writes 45994
Max_used_connections 100
Not_flushed_key_blocks 8004
Not_flushed_delayed_rows 0
Open_tables 114
Open_files 223
Open_streams 0
Opened_tables 128449
Questions 738278
Qcache_queries_in_cache 0
Qcache_inserts 0
Qcache_hits 0
Qcache_lowmem_prunes 0
Qcache_not_cached 0
Qcache_free_memory 0
Qcache_free_blocks 0
Qcache_total_blocks 0
Rpl_status NULL
Select_full_join 0
Select_full_range_join 0
Select_range 6939
Select_range_check 0
Select_scan 108058
Slave_open_temp_tables 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 6640
Sort_merge_passes 420
Sort_range 807
Sort_rows 4937160
Sort_scan 34248
Table_locks_immediate 1019951
Table_locks_waited 9901
Threads_cached 0
Threads_created 76093
Threads_connected 101
Threads_running 96
Uptime 181370
 
QUOTE (dandelion @ Di 18.4.2006, 18:37)[...] Die Datenbank-Tables sind indexiert, ich glaube nicht, dass ich die Zugriffs-Statements noch optimieren könnte. Ich vermute (hoffe...) , man kann mySQL aber noch optimieren, [...]

Wenn Du dies vermutest, muss Du wohl schon selber ran. Das optimieren der MySQL-Datenbank hängt insbesondere von Verständnis der technischen Funktionsweise des MySQL-Servers ab und wie der Dienst mit welchen Datenbanktypen umgeht.
Auch kann eine Optimierung nur dadurch erfolgen, indem man mit den wirklichen Daten arbeiten und den Ablauf visualisieren kann.
Wann treten besonders große Engpässe auf? Welche Abfrage sind besonders langsam und vieles mehr?


Ich kann Dir hierbei das Buch "High Performance MySQL" [1] aus dem O'Reilly Verlag empfehlen.



MfG Sascha Ahlers

[1] O'Reilly: High Performance MySQL
 
QUOTE es handelt sich um einen Root-Server...
(bei Hosteurope...


Pflegst Du diesen Root Server selber oder macht das HE?

Bei HE habe ich ein grosses CMS am laufen und stelle die gleichen Fehler wie Du fest.



QUOTE can't connect to database

genau so ist es bei mir auch.
In den Logfiles stelle icht fest, dass es häufig am Mittag zu diesen Problemen führt.
Warum das so ist, kann ich nicht beurteilen. Auch der HE Support findet keine Lösung, resp. geben jeweils den Skripten die Schuld.


Gruss

Rolf
 
Ich verwende kein mySql, insofern kann ich nur spekulieren.

Aber: HE wird mit Sicherheit nicht die Scripte pflegen, das gehört ja nicht zum Betriebssystem. Also liegt das Problem außerhalb eines eventuellen managed Servers.

Slow_queries 6640 ist doch eindeutig.

Max_used_connections 100 - mittags werden mehr als 100 Leute drauf zugreifen, in Kombination mit zu langsamen Abfragen blockiert das.
 
Wenn du wirklich Root-Rechte hast dort, schalte mal das "mysql-log-slowquerys" in der /etc/mysql/my.cnf ein (Danach mySQL-Dämon neu starten). Jetzt loggt er dir alle zu langsamen Querys im angegebenen File. Diese kannst du dann z.B. mit "EXPLAIN SELECT blabblab.." analysieren, und schauen welche von deinen Indexen er wirklich verwenden kann.

Ansonsten mal mit dem mySQL-Cache rumspielen. Ebenfalls kann ein PHP-Beschleuniger wahre Wunder vollbringen. Ich verwenden den Turck mmcache und bin sehr überzeugt davon.

Welchen Apache verwendest du, den 1.3er, oder den 2er?
 
Hallo,

Vielen Dank für Eure bisherigen Tipps und Eure Unterstützung !
Ich werde als erstes Mal die slow-queries loggen ; vielleicht ergeben sich da interessante Hinweise.


Grundsätzlich stellt sich mir schlicht die Frage, ob irgendwelche Tuning-Massnahmen nur Tropfen auf den heissen Stein
sind oder ob ich halt einfach auf einen stärkeren Server (Prozessor, RAM etc) wechseln muss.
Es wäre einfach ärgerlich, wenn man dann dieselben Probleme auf dem neuen (teureren !) Server ebenfalls hat..

Gruss und Danke
Philipp

P.S. Verwende Apache/2.0.49 (Linux/SuSE)
 
Da hier niemand deine Abfragen kennt ist die Frage ob du eine stärkere Maschine brauchst nicht seriös zu beantworten.
Grundsätzlich sind 3000 User aber mal nicht so schlimm, wobei natürlich eine Frage ist wie deine Spitzen aussehen und was denn so gemacht wird. Wenn man die Zugriffsrechte hat kann man einiges Tunen, aber da würde ich Schrittweise vorgehen:

Ist das Application Design performant? (oft im Nachhinein nicht so leicht zu ändern)
Sind die Abfragen performant, ist der Code performant? (da geht überraschend viel)
Tuning Server

Cachen kann wenn möglich wirklich viel einsparen.
 
Also am Server wirds mit aller Garantie nicht liegen. der hat locker genug Power, um das von dir beschriebene Umfeld zu betreiben.

Hängst du fest an deinem Apache 2? Teste sonst das ganze mal mit dem 1.3er.

Ich betreibe den Server für ne grössere Community mit ~10'000 Mitglieder, und weit über 600'000 Postings. (Rund 800MB mySQL-Daten). Auf der alten Umgebung lief das ganze ähnlich wie von dir beschrieben schlecht.

Seit rund einem Monat bin ich auf eine neue Umgebung umgezogen damit, und habe das ganze weitgehend optimiert. Jetzt läuft es Pippifein, mit einer Seitenaufbauzeit <0.3s

Nachdem ich das Setup fast 1:1 übernommen habe, musste ich feststellen, dass die Performance nicht wirklich verbessert wurde. Danach habe ich mal den Turck-Beschleuniger aufgezogen, den Query-Cache optimiert, sowie die Struktur der DB selbst optimiert (z.B. überflüssige Indexe rausgehauen). Danach wars zwar besser, aber noch immer nicht erfreulich gut. In letzter Verzweiflung habe ich danach mal vom Apache 2 auf den 1.3 gedowngradet, und nur die nötigsten Module/Erweiterungen geladen. Seither läuft es perfekt. CPU-Load geht zu Stosszeiten auf rund 20%.

Ist auch "nur" ein P4-3.0 mit 1GB Ram unter Debian.

Eine weitere Performancebremse können brutal grosse Logs sein, wie z.B. vom Webalizer oder ähnliches. Also schauen ob ein Logrotate sauber auf allen wichtigen Logs läuft.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben