Drupal stürz ab wenn sich mehrere User gleichzeitig einloggen; Swap-File
Eingetragen von talueng (48)am 28.05.2010 - 09:57 Uhr in
Wir haben das folgende Problem mit unserem Drupal-Intranet, das auf einem Hosting-Provider läuft:
In unserem ersten Training stürzte das System ab, als sich 5-10 Mitarbeiter gleichzeitig einloggen wollten. Ich bin mir nicht sicher, was genau abstürzte, aber es liess sich einfach keine Drupal-Seite mehr laden. Das Laden dauerte und dauerte... nicht mal eine Fehlermeldung (404, oder so) kam. Irgendwann dann kam zumindest die Drupal "Site in maintenance mode" message.
FTP server und phpMyAdmin waren weiterhin erreichbar; Server und Datenbankserver schienen also zu laufen.
Unser Hostingprovider sagt, es sei ein Problem unserer Software. Allerdings nutzen wir eine Standard Drupal 6-Installation mit CCK, Views, usw. Insofern weiss ich nicht, inwieweit das Problem bei uns liegen könnte.
Nach Argumentation unseres Hosters sei die Swap-file (2 GB) zu schnell voll; unsere Software würde bis zu 70% davon benutzen, während es eigentlich nur 10% sein sollten. Sie haben die folgenden Reports ihres Monitoring-Tools angehangen, die ich allerdings nicht verstehe:
http://img338.imageshack.us/img338/6410/100525swap1.jpg
http://img697.imageshack.us/img697/7562/100525swap2.jpg
http://img189.imageshack.us/img189/1083/100525swap3.jpg
http://img248.imageshack.us/img248/3631/100525swap4.jpg
Weitere Informationen, die von Belang sein könnten:
- Die "Site in maintenance mode" message sagt ferner: "The MySQL error was: Too many connections." (soweit ich mich recht erinnere; gibt es irgendein Log-File, wo ich mich vergewissern könnte?)
- In phpMyAdmin sehe ich, dass viele Drupal-Tabelle als "Overhead" (Überlauf) markiert sind, insbesondere die Tabellen "cache_form" (24.8 MiB) und "watchdog" (22.7 MiB); insgesamt ist der Überhang 49.1 MiB, plus 63.8 MiB Tabellengröße
- Ein "Check Table" über alle Tabellen besagt dass "1 client is using or hasn't closed the table prope..." (oder sogar 2 clients, etc.) für eine große Zahl Tabellen (allerdings ist diese Meldung jetzt wieder verschwunden)
Hat jemand eine Ahnung, warum das passieren könnte? Weiss jemand, ob ich unser Drupal mal auf einem anderen Server laufen lassen könnte, um es dort zu testen?
- Anmelden oder Registrieren um Kommentare zu schreiben
Ist das ein ganz normales
am 28.05.2010 - 11:01 Uhr
Ist das ein ganz normales "shared hosting" Paket von eurem Anbieter ?
Wenn das Swapfile voll läuft , dann deutet das auf viel zu wenig Arbeitsspeicher des Servers hin. ( oder zu viele Kunden auf dem Server )
Dasselbe ist bei der Fehlermeldung "The MySQL error was: Too many connections" ( Auch zu viele Kunden die den SQL Server benutzen )
Wenns ein "shared hosting" Paket ist , kannst du leider von deiner Seite aus nix machen.
Gib uns doch mal ein paar
am 28.05.2010 - 12:05 Uhr
Gib uns doch mal ein paar Eckdaten zu eurem Hosting-Paket. Ich nehme an es handelt sich um einen vServer? Hast du einen SSH Zugang?
Grundsätzlich sollte ein Webserver nach Möglichkeit gar nicht genötigt sein den Swap zu nutzen. Sobald benötigte Daten auf die Platte ausgelagert werden müssen beginnt ein Teufelskreis, da Anfragen nun noch langsamer beantwortet werden können, während ungeduldige User per Reload noch mehr Requests anstoßen. Am Ende läuft der Swap voll, der Server kann auf Anfragen nicht mehr reagieren, weil er damit ausgelastet ist von Platte zu lesen und darauf zu schreiben. Durch die zwischenzeitlich auflaufenden Anfragen kann es dann auch zu der "Too many connections" Fehlermeldung von MySQL kommen. Die ist dann aber ein Folgefehler und kein ursächlicher Fehler.
Zunächst mal danke für Eure
am 28.05.2010 - 13:10 Uhr
Zunächst mal danke für Eure beiden Antworten. Leider habe ich von der Serverseite zu wenig Ahnung; ich komme aus dem Webdevelopment bzw. der Drupalseite.
Zur Frage nach dem Hostingpaket: Wir haben unserem Provider eine genaue Spezifikation der Requirements gegeben, die denen entspricht, wie sie auch im Drupal Handbook vorgeschlagen wird. Trotz dieser Spezifikation hat uns der Provider zunächst auf ein Shared Hosting gepackt (wo natürlich viele Sachen nicht funktionierten), woraufhin wir ihn darauf hingewiesen haben, dass es nicht unserer Spezifikation entspricht. Nach einigen Hin- und Her hat man uns dann angeblich einen eigenen Server eingerichtet, wobei auch dieser immer noch stark eingeschränkt ist, d.h. wir haben nur Zugang per FTP und mySQL, mussten .htaccess erst ausdrücklich aktivieren lassen, usw.
Insofern kann ich selbst auch nicht mehr Angaben zur Serverkonfiguration machen (ausser vielleicht der Ausgabe von phpInfo() hier (PDF)), aber wenn Ihr mir sagt, welche Informationen Ihr zur Einschätzung benötigt, würde ich diese bei unserem Provider anfragen und Euch hier weiterleiten.
Hallo,wichtig wäre zu wissen
am 28.05.2010 - 14:51 Uhr
Hallo,
wichtig wäre zu wissen , wieviel RAM der Server hat , und liegt der SQL Server auf der selben Maschine ?
Ich hab mir grad mal die Webseite angeschaut , und muss sagen das die ganz schön langsam ist. ( sehr untypisch für eine BSD Maschine )
und die ping laufzeiten sind ja auch die hölle >300ms *g* ...steht der Server irgendwo am nordpol ?
kleines Update :
Sieht so aus als ob ihr nur nen vServer bekommen habt. ( sind noch weitere 19 Domains auf der Maschine )
Wenn da einge Seiten mit massig Traffic bei sind , erklären sich eure Probleme.
kleines Beispiel: www.arowana-world.com liegt auch auf der IP ... und ist auch grottenlangsam :-)
Jetzt würde mich erstmal
am 28.05.2010 - 19:07 Uhr
Jetzt würde mich erstmal interessieren, wie Du unsere Seite rausbekommen hast; habe doch extra alle Domainnamen in dem phpInfo()-PDF file geschwärzt. ;-)
Allerdings hast Du recht, die Seite ist trotz Caching sehr langsam. Ein weiterer Punkt, der uns aufstößt. Was kann ich am besten unserem Hosting-Provider sagen? Deren Position ist momentan, dass die Schuld bei unserer Software zu suchen ist. (Der Server dürfte übrigens in Thailand stehen, allerdings handelt es sich bei dem Intranet auch um ein Intranet für ein Unternehmen in Thailand.)
// edit: Kannst Du mir außerdem noch sagen, mit welchem Service Du die Informationen rauskriegst, welche und wieviele andere Kunden noch auf dem Server laufen? Ich nehme an, dass es irgendein Reverse-IP service sein muss, allerdings spucken die mir bislang keine vernünftigen Informationen aus..
// edit2: Folgende Ausgabe stammt vom dbtuner Modul. In der Drupal-Group High Performance wurde ich gebeten, die Ausgabe zu Analysezwecken zu posten, daher tue ich das hier auch mal (in der Hoffnung, dass damit jemand etwas anfangen kann):
Queries
Uptime in seconds: 121800
Uptime: 1d 9h 50m 0s
Questions: 118427
% slow queries: 0
slow query rate: 0 per day
Long query time: 10
long_query_time is set to 10 seconds or more. This may not be appropriate for your environment.
(long_query_time >=10)
(10.000000 10>=10)
Slow query logging: OFF
Enable the slow query log to troubleshoot bad queries.
("log_slow_queries" eq 'OFF')
("OFF" OFF=== 'OFF')
% reads: 51.616701385744
% writes: 48.383298614256
qps: 0.97230706075534
reads per sec: 0.36614802953434 per day
writes per sec: 0.34321157637699 per day
Queries: 58.33842364532 per minute
Connections: 3 Thousand
Bytes sent: 400 Million
Bytes received: 35 Million
versions
Supported Version: 5
Release Series: 5.1
Minor Version: 40
Distribution: FreeBSD port: mysql-server-5.1.40
Distribution: FreeBSD port: mysql-server-5.1.40
MySQL Architecture: i386
MySQL is not compiled as a 64-bit package.
("version_compile_machine" !~ /64/)
("i386" dbtuner_strnistr('i386 ', array('64')))
Query cache
Query cache efficiency (%): 80.776928266247
% query cache used: 65.871858596802
The query cache is not being fully utilized.
(Qcache_free_memory / query_cache_size * 100 <80)
(11051464 / 16777216 * 100 65.871858596802<80)
Query cache low memory prunes: 0 per day
Query cache size: 16.0 Mb
Query cache min result size: 1.0 Mb
The max size of the result set in the query cache is the default of 1 Mb. Changing this (usually by increasing) may increase efficiency.
(&hr_bytes(query_cache_limit) eq "1.0 Mb")
(dbtuner_hr_bytes(1048576) '1.0 Mb' === "1.0 Mb")
Sorts
Total sorts: 3014
% sorts that cause temporary tables: 0
rate of sorts that cause temporary tables: 0 per day
sort_buffer_size: 1.0 Mb
read_rnd_buffer_size: 4.0 Mb
Sort rows: 15.971428571429 per minute
There are lots of rows being sorted. Consider using indexes in more queries to avoid sorting too often.
(&hr_bytime(Sort_rows/Uptime_since_flush_status) =~ /second|minute/)
(dbtuner_hr_bytime(32422/121800) dbtuner_stristr('15.971428571429 per minute', array('second', 'minute')))
Joins,scans
rate of joins without indexes: 1.1029556650246 per minute
There are too many joins without indexes -- this means that joins are doing full table scans.
(&hr_bytime((Select_range_check + Select_scan + Select_full_join)/Uptime_since_flush_status) =~ /second|minute/)
(dbtuner_hr_bytime((0 + 2139 + 100)/121800) dbtuner_stristr('1.1029556650246 per minute', array('second', 'minute')))
rate of reading first index entry: 21.270443349754 per minute
The rate of reading the first index entry is high; this usually indicates frequent full index scans.
(&hr_bytime(Handler_read_first/Uptime_since_flush_status) =~ /second|minute/)
(dbtuner_hr_bytime(43179/121800) dbtuner_stristr('21.270443349754 per minute', array('second', 'minute')))
rate of reading fixed position: 14.779310344828 per minute
The rate of reading data from a fixed position is high; this indicates many queries need to sort results and/or do a full table scan, including join queries that do not use indexes.
(&hr_bytime(Handler_read_rnd/Uptime_since_flush_status) =~ /second|minute/)
(dbtuner_hr_bytime(30002/121800) dbtuner_stristr('14.779310344828 per minute', array('second', 'minute')))
rate of reading next table row: 3.2516666666667 per second
The rate of reading the next table row is high; this indicates many queries are doing full table scans.
(&hr_bytime(Handler_read_rnd_next/Uptime_since_flush_status) =~ /second|minute/)
(dbtuner_hr_bytime(396053/121800) dbtuner_stristr('3.2516666666667 per second', array('second', 'minute')))
temp tables
tmp_table_size-max_heap_table_size: 0
tmp_table_size: 16.0 Mb
max_heap_table_size: 16.0 Mb
% temp disk tables: 43.432494279176
Too many temporary tables are being written to disk. Increase max_heap_table_size and tmp_table_size.
(Created_tmp_disk_tables / (Created_tmp_tables + Created_tmp_disk_tables) * 100 >25)
(949 / (1236 + 949) * 100 43.432494279176>25)
temp disk rate: 28.049261083744 per hour
temp table rate: 36.532019704433 per hour
MyISAM index cache
MyISAM key buffer size: 256.0 Mb
max % MyISAM key buffer ever used: 0.34294128417969
MyISAM key buffer (index cache) % used is low. You may need to decrease the size of key_buffer_size, re-examine your tables to see if indexes have been removed, or examine queries and expectations about what indexes are being used.
((Key_blocks_used)*key_cache_block_size/key_buffer_size * 100 <95)
((899)*1024/268435456 * 100 0.34294128417969<95)
% MyISAM key buffer used: 11.857223510742
MyISAM key buffer (index cache) % used is low. You may need to decrease the size of key_buffer_size, re-examine your tables to see if indexes have been removed, or examine queries and expectations about what indexes are being used.
((1-Key_blocks_unused*key_cache_block_size/key_buffer_size) * 100 <95)
((1-231061*1024/268435456) * 100 11.857223510742<95)
% index reads from memory: 99.958481913593
other caches
table open cache size (5.1+): 256
Size of the table cache
(table_open_cache >-1)
(256 256>-1)
rate of table open: 6.2955665024631 per hour
% open files: 2.7309598918432
rate of open files: 8.9556650246305 per hour
Immediate table locks %: 99.736768542676
Table lock wait rate: 3.3399014778325 per hour
thread cache: 8
Total threads created: 601
thread cache hit rate %: 0.15434001027221
Threads that are slow to launch: 0
Slow launch time: 2
Connections
% connections used: 10.596026490066
Max connections used: 16
Max connections limit: 151
% aborted connections: 0.51361068310221
rate of aborted connections: 14.187192118227 per day
% aborted clients: 0
rate of aborted clients: 0 per day
InnoDB
Is InnoDB enabled?: YES
% innoDB log size: 62.5
InnoDB log file size is not an appropriate size, in relation to the InnoDB buffer pool. Consider changing either\ninnodb_log_file_size or innodb_buffer_pool_size
(innodb_log_file_size / innodb_buffer_pool_size * 100 >=0)
(5242880 / 8388608 * 100 62.5>=0)
other
MyISAM concurrent inserts: 1
INSERT DELAYED USAGE
Delayed_errors 0
Delayed_insert_threads 0
Delayed_writes 0
Not_flushed_delayed_rows
Im Internet ist niemand
am 31.05.2010 - 07:17 Uhr
Im Internet ist niemand "anonym" und eine phpinfo() sagt mehr als 1000 worte :-)
Um rauszufinden , welche domains noch auf deiner IP Laufen , hab ich http://www.domaintools.com/reverse-ip/ benutzt.
Musst nur als Hostnamen , deinen HOSTNAMEN aus der phpinfo() da eintragen ( ist irgendwas mit "3gig" , wenn ich mich jetzt nicht irre )
lg
...deswegen hatte ich
am 31.05.2010 - 10:38 Uhr
...deswegen hatte ich eigentlich vorher alle Domainnamen aus der PHPInfo() geschwärzt. War ich wohl etwas schlampig und habe welche vergessen... ;-)
3gig ist soweit ich weiss irgendwas von unserem Anbietet. Unsere Domain ist www.bgrimmcafe.com
Unser Hosting Provider hat
am 01.06.2010 - 11:35 Uhr
Unser Hosting Provider hat nochmal bestätigt, dass wir einen eigenen Server haben und uns keinen Server mit anderen Kunden teilen. Auch arowana-world.com sei auf einem anderen Server untergebracht.
Ausserdem habe man jetzt Swap-File von 2GB auf 8GB vergrößert und den RAM auf 1GB. Sind diese Werte Eurer Meinung nach in Ordnung? Die Seite läuft immer noch wahnsinnig langsam.. Ich bin momentan aber auch in Deutschland und die Seite liegt auf einem thailändischen Server.
Ausserdem habe ich jetzt SSH und VMWare access bekommen. Wenn Ihr mir sagt, welche Informationen Ihr braucht bzw. welche Einstellungen ich ändern sollte, kann ich das jetzt machen.
Eine größere Swap-Datei ist
am 01.06.2010 - 14:40 Uhr
Eine größere Swap-Datei ist für einen Webserver Humbug. Und VMWare Access und "eigener Server" (im Sinne von dediziertem Root-Server) schließen sich schonmal aus. Damit ist auch klar, dass du eindeutig NICHT alleine auf dem physischen Server bist (Wozu sonst VMWAre?).
Da passt irgendwie nicht viel zusammen. Gibt es keine ordentlichen Hoster in Thailand?
Zitat: Eine größere
am 01.06.2010 - 14:56 Uhr
Eine größere Swap-Datei ist für einen Webserver Humbug. Und VMWare Access und "eigener Server" (im Sinne von dediziertem Root-Server) schließen sich schonmal aus. Damit ist auch klar, dass du eindeutig NICHT alleine auf dem physischen Server bist (Wozu sonst VMWAre?).
Interessant. Ich muss zugeben, dass ich nicht viel Ahnung von der Server/Hardware/Hosting-Seite habe. Deswegen sind solche Hinweise für mich auch sehr wichtig. Die Aussage des Hosters war: "the virtual server that we provide to [you] is not sharing with others customers and for arowana-world.com is on another server." Gibt es eine Möglichkeit herauszufinden, ob wir tatsächlich mit anderen Kunden auf einem Server liegen? Ich brauche ja irgendeine Argumentation; gerade deshalb, da ich von der Server/Hosting-Seite nicht viel Ahnung habe, fällt es mir schwer, einfach zu behaupten, dass da noch andere Kunden mit auf dem Server sind. Kann ich das mit dem SSH/VMWare-Zugang irgendwie herausfinden?
Gibt es keine ordentlichen Hoster in Thailand?
Der jetzige Hoster gehört mit zu den größten und bekanntesten und wurde uns von einer IT-Consulting (die ebenfalls zu den größten und bekanntesten gehören) empfohlen.
Also, ihr habt einen
am 01.06.2010 - 15:13 Uhr
Also, ihr habt einen virtuellen Server. Dieser teilt sich mit x anderen virtuellen Server denselben physischen Server. Wenn du sagst die haben euren RAM auf 1 GB HOCHgesetzt, denke ich mal hattet ihr vorher so 512 MB RAM? Gehen wir davon aus, dass ein Server er aktuellen Generation zwischen 8 und 12 GB RAM hat, würde man dort also mit 16 bis 24 virtuellen Servern, also 15 bis 23 anderen Kunden auf derselben Maschine rechnen können. Diese teilen sich CPU, I/O Performance (RAM-Durchsatz, Netzwerkanbindung, Festplattendurchsatz, etc.). Sobald auch nur eine der virtuellen Machinen swappt, zieht das die Performance aller runter.
Also irgendwie haben wir alle Recht ;)
Hast du evtl. Zugriff (Fernwartung, VNC, Teamviewer, o.ä) auf einen Client-Rechner in Thailand um darüber die lokale Performance zu messen? Diese ist natürlich eine andere, als wenn sich alles erst noch über die kleinen Leitungen aus Asien hierher quälen muss...
Zitat: Hast du evtl. Zugriff
am 01.06.2010 - 15:27 Uhr
Hast du evtl. Zugriff (Fernwartung, VNC, Teamviewer, o.ä) auf einen Client-Rechner in Thailand um darüber die lokale Performance zu messen? Diese ist natürlich eine andere, als wenn sich alles erst noch über die kleinen Leitungen aus Asien hierher quälen muss...
Leider nein. Ich könnte unsere IT-Jungs vor Ort im Office mal fragen, wie die die Performance dort jetzt einschätzen. Im Drupal.org Forum hat ausserdem jemand vorgeschlagen, dass selbst 1GB immer noch zu wenig seien. Auch dort habe ich gefragt, was man für ein Firmenintranet mit ca. 450 Mitarbeitern am besten braucht. Wir hatten anfangs keine Angaben zur Performance bzw. Nutzung gemacht, sondern hauptsächlich die technischen Requirements für eine Drupal-Installation sichergestellt. Insofern hat man uns erst ein (falsch konfiguriertes) Shared-Hosting gegeben und jetzt offenbar einen (technisch richtig konfigurierten, aber leistungsmäßig zu schwachen) Virtual Server.