Hallo zusammen,
Ich bin ziemlich neu hier, würde mich aber sehr freuen, wenn mir jemand weiterhelfen könnte.
Ich habe vor ca. 1 Monat eine Website mit einer gekauften web 2.0 Software aufgeschaltet. Die Seite hat innert kürzester Zeit ziemlich viel Traffic erhalten, durchschnittlich 1'000 neue Sign Ups pro Tag und etwa 5'000 Unique Visitors. Zur Software hab ich noch ein Hosting Paket von 20$ gekauft. Aufgrund des Traffics wurde schnell klar, dass ich mir einen dedicated Server zulegen musste. Seit ein paar Wochen habe ich nun einen dedicated Server.
Mit dem neuen Linux Server habe ich aber nur Probleme, aber hier erstmals die Spezifikationen:
4x CPU:
Ein grosses Problem ist meiner Meinung nach vor allem der MySQL Server. Er braucht teilweise für einige Minuten 100% des CPU und stürzt dann manchmal ab und folgende Error Message ist zu lesen:
Oder etwas ähnliches:
Aufgrund dieser Probleme hat mir die Hosting Firma empfohlen 2gb ram zusätzlich zu kaufen und Nginx Webserver aufzusetzen, der all die Datenbank Anfragen besser verarbeiten kann. Ich habe nun die 2gb ram gekauft und die wurden heute morgen eingebaut. Dennoch hat sich das Problem kaum gebessert. Es gab immer noch dieselben Fehlermeldungen und der Server stürtzte immer wieder ab.
Hier vielleicht noch einige nützliche Infos:
Disk usage:
Servertraffic Statistiken:
Abfragestatistiken:
Jemand der sich mit MySQL Problemen auskennt, hat mir folgendes dazu geschrieben:
* Query types: 83'000 SELECT, 5'5000 UPDATE, 6'000 SET OPTION.
Also gibt es 23 Select-Anfragen pro Sekunde. Das ist natürlich sehr
viel. Es wird also auf Applikationsebene wahrscheinlich nichts
gecachet, sondern alles direkt aus der DB geholt.
Ausserdem ist es komisch, dass es so viele "SET OPTION" Queries gibt.
Das macht eigentlich keinen Sinn so häufig, irgendwas komisches..
* 1'423'000 Requests mit Tablescan, 685'000'000 Requests mit Tablescan
und/oder schlechtem/keinem Index.
Requests mit Tablescan kommen eben vorallem vor, wenn schlechte bzw.
keine Indizes der Tabellen vorhanden sind. Das verlangsamt die DB u.U.
extrem.
CPU Usage:
Hierzu habe ich leider keine Statistiken, ich kann nur sagen, dass die CPU Auslastung wie irre hin und her springt zwischen 1% und dann in der nächsten Sekunde zu 99.9%. Angezeigt wird dann jeweils, dass immer der MySQL Server den ganzen CPU braucht. Dies bleibt dann manchmal s für mehrere Minuten und der MySQL Server stürzt komplett ab oder es beruhigt sich wieder. Seltsam scheint mir aber, dass trotz der extremen CPU Auslastung die ram Auslastung dieselbe bleibt (vorher bei 1gb ram ca. 0.4gb ram used und 0.6gb ram free und jetzt mit 3gb ram ca. 1.2gb ram used und 1.8gb ram free). Die Serverload ist in diesen Momenten dann auch bei etwa 1.5 schwankt dann aber auch wieder zurück zu 0.1.
Im PHP MyAdmin sind folgende Variablen rot markiert:
* Slow_queries 15 Anzahl der Anfragen, die länger als long_query_time benötigten.
* Innodb_buffer_pool_reads 13 Anzahl an Lesevorgängen die InnoDB nicht aus dem Zwischenspeicher bedienen konnte und deshalb einen Einzel-Seiten-Lesevorgang starten musste.
* Handler_read_rnd 6,215 k Anzahl der Anfragen, eine Zeile basierend auf einer festen Position zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Anfragen ausführen, die erfordern, dass das Ergebnis sortiert wird. Wenn Handler_read_rnd hoch ist, haben Sie wahrscheinlich viele Anfragen, die MySQL zwingen, ganze Tabellen zu scannen, oder Sie haben Joins, die Schlüssel nicht richtig benutzen.
* Handler_read_rnd_next 701 M Anzahl der Anfragen, die nächste Zeile in der Daten-Datei zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Tabellen-Scans durchführen
* Created_tmp_disk_tables 1,245 Anzahl der (implizit) auf der Platte erzeugten temporären Tabellen bei der Ausführung von Statements.
* Select_full_join 16 k Anzahl der Joins ohne Schlüssel. Wenn dieser Wert nicht 0 ist sollten die Indizes der Tabellen sorgfältig überprüft werden.
* Opened_tables 267 Anzahl der Tabellen, die geöffnet wurden. Wenn Opened_tables hoch ist, ist Ihre table_cache-Variable wahrscheinlich zu niedrig.
* Table_locks_waited 908 Wie oft eine Tabellensperre nicht sofort erlangt werden konnte und gewartet werden musste. Wenn dieser Wert hoch ist und Sie Performance-Probleme haben, sollten Sie zunächst Ihre Anfragen optimieren und dann entweder Ihre Tabelle
zerteilen oder Replikation benutzen.
-----------------------------
Seltsam finde ich, dass mein alter Hostin plan für 20$ mit gut 70 Leuten gleichzeitig auf der Seite ohne weiteres zu Rande kam, dass aber der neue Server für das 20fache vom Preis schon mit 30 Leuten gleichzeitig Mühe hat und abstürzt. Da kann irgendetwas nicht stimmen.
Ich würde mich sehr freuen, wenn mir jemand weiterhelfen könnte. Denn seit ich den neuen Server habe ist der Traffic massiv gesunken und auch sonst ist es einfach sehr mühsam. Könnte es sein, das es einfach an der Software liegt, die vielleicht schlecht cached und indexiert und darum viele aufwendige Datenbanken Zugriffe macht?
Das angehängte Bild zeigt die Down-/Uptime des Servers (Ein Monitor Skript hat jede Minute versucht auf die Seite zuzugreifen) innerhalb von 48 Stunden. Obere Linie zeigt Uptime, untere Downtime.
Besten Dank,
Michael
MOD: Bitte [noparse]
[/noparse]-Tags um Ausgaben, Code, etc. verwenden (im Editor auch mit '#' erreichbar). Danke!
Ich bin ziemlich neu hier, würde mich aber sehr freuen, wenn mir jemand weiterhelfen könnte.
Ich habe vor ca. 1 Monat eine Website mit einer gekauften web 2.0 Software aufgeschaltet. Die Seite hat innert kürzester Zeit ziemlich viel Traffic erhalten, durchschnittlich 1'000 neue Sign Ups pro Tag und etwa 5'000 Unique Visitors. Zur Software hab ich noch ein Hosting Paket von 20$ gekauft. Aufgrund des Traffics wurde schnell klar, dass ich mir einen dedicated Server zulegen musste. Seit ein paar Wochen habe ich nun einen dedicated Server.
Mit dem neuen Linux Server habe ich aber nur Probleme, aber hier erstmals die Spezifikationen:
4x CPU:
Code:
Processor #1 Vendor: GenuineIntel
Processor #1 Name: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz
Processor #1 speed: 2399.883 MHz
Processor #1 cache size: 4096 KB
Code:
Memory for crash kernel (0x0 to 0x0) notwithin permissible range
Memory: 3110964k/3144512k available (2122k kernel code, 32144k reserved, 883k data, 228k init, 2227008k highmem)
Memory
total used free shared buffers cached
Mem: 3114708 1016724 2097984 0 52856 411824
-/+ buffers/cache: 552044 2562664
Swap: 2096472 0 2096472
Total: 5211180 1016724 4194456Ein grosses Problem ist meiner Meinung nach vor allem der MySQL Server. Er braucht teilweise für einige Minuten 100% des CPU und stürzt dann manchmal ab und folgende Error Message ist zu lesen:
Code:
Warning: SK_MySQL::connect() database connection failed in /home/public_html/internals/API/MySQL.class.php on line 17
Warning: mysql_real_escape_string() expects parameter 2 to be resource, boolean given in /home/public_html/internals/API/MySQL.class.php on line 35
Warning: mysql_query(): supplied argument is not a valid MySQL-Link resource in /home/public_html/internals/API/MySQL.class.php on line 161
Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource in /home/public_html/internals/API/MySQL.class.php on line 165
Warning: mysql_errno(): supplied argument is not a valid MySQL-Link resource in /home/public_html/internals/API/MySQL.class.php on line 166
Uncaught exception with message: code: 0
Trace:
#0 /home/public_html/internals/API/Config.class.php(49): SK_MySQL::query('SELECT `config_...')
#1 /home/public_html/internals/API/Config.class.php(18): SK_Config_Section->__construct('video')
#2 /home/public_html/internals/Header.inc.php(262): SK_Config::section('video')
#3 /home/public_html/index.php(3): require_once('/home/...')
#4 {main}
thrown in: /home/public_html/internals/API/MySQL.class.php on line 164Oder etwas ähnliches:
Code:
Uncaught exception with message: MySQL server has gone away code: 2006
Trace:
#0 /home/public_html/internals/Apps/Profile.app.php(564): SK_MySQL::query('SELECT `profile...')
#1 /home/public_html/internals/API/HttpUser.class.php(40): app_Profile::updateProfileActivity()
#2 /home/public_html/internals/Header.inc.php(321): SK_HttpUser::session_start()
#3 /home/public_html/index.php(3): require_once('/home/...')
#4 {main}
thrown in: /home/public_html/internals/API/MySQL.class.php on line 164Aufgrund dieser Probleme hat mir die Hosting Firma empfohlen 2gb ram zusätzlich zu kaufen und Nginx Webserver aufzusetzen, der all die Datenbank Anfragen besser verarbeiten kann. Ich habe nun die 2gb ram gekauft und die wurden heute morgen eingebaut. Dennoch hat sich das Problem kaum gebessert. Es gab immer noch dieselben Fehlermeldungen und der Server stürtzte immer wieder ab.
Hier vielleicht noch einige nützliche Infos:
Disk usage:
Code:
Device Size Used Available Percent Used Mount Point
/dev/sda1 99M 17M 78M 18% /boot
/dev/sda3 2.0G 40M 1.8G 3% /tmp
/dev/sda5 223G 7.7G 204G 4% /Servertraffic Statistiken:
Code:
Traffic Tip ø pro Stunde
Empfangen 187 MiB 73 MiB
Gesendet 505 MiB 196 MiB
Insgesamt 692 MiB 269 MiB
Verbindungen ø pro Stunde %
max. gleichzeitige Verbindungen 47 --- ---
Fehlgeschlagen 0 0,00 0,00%
Abgebrochen 183 71,11 1,45%
Insgesamt 13 k 4,898,18 100,00%Abfragestatistiken:
Code:
Abfragestatistik: Seit seinem Start wurden 1,509,513 Abfragen an diesen MySQL-Server gesandt.
Insgesamt ø pro Stunde ø pro Minute ø pro Sekunde
1,510 k 586,54 k 9,78 k 162,93Jemand der sich mit MySQL Problemen auskennt, hat mir folgendes dazu geschrieben:
* Query types: 83'000 SELECT, 5'5000 UPDATE, 6'000 SET OPTION.
Also gibt es 23 Select-Anfragen pro Sekunde. Das ist natürlich sehr
viel. Es wird also auf Applikationsebene wahrscheinlich nichts
gecachet, sondern alles direkt aus der DB geholt.
Ausserdem ist es komisch, dass es so viele "SET OPTION" Queries gibt.
Das macht eigentlich keinen Sinn so häufig, irgendwas komisches..
* 1'423'000 Requests mit Tablescan, 685'000'000 Requests mit Tablescan
und/oder schlechtem/keinem Index.
Requests mit Tablescan kommen eben vorallem vor, wenn schlechte bzw.
keine Indizes der Tabellen vorhanden sind. Das verlangsamt die DB u.U.
extrem.
CPU Usage:
Hierzu habe ich leider keine Statistiken, ich kann nur sagen, dass die CPU Auslastung wie irre hin und her springt zwischen 1% und dann in der nächsten Sekunde zu 99.9%. Angezeigt wird dann jeweils, dass immer der MySQL Server den ganzen CPU braucht. Dies bleibt dann manchmal s für mehrere Minuten und der MySQL Server stürzt komplett ab oder es beruhigt sich wieder. Seltsam scheint mir aber, dass trotz der extremen CPU Auslastung die ram Auslastung dieselbe bleibt (vorher bei 1gb ram ca. 0.4gb ram used und 0.6gb ram free und jetzt mit 3gb ram ca. 1.2gb ram used und 1.8gb ram free). Die Serverload ist in diesen Momenten dann auch bei etwa 1.5 schwankt dann aber auch wieder zurück zu 0.1.
Im PHP MyAdmin sind folgende Variablen rot markiert:
* Slow_queries 15 Anzahl der Anfragen, die länger als long_query_time benötigten.
* Innodb_buffer_pool_reads 13 Anzahl an Lesevorgängen die InnoDB nicht aus dem Zwischenspeicher bedienen konnte und deshalb einen Einzel-Seiten-Lesevorgang starten musste.
* Handler_read_rnd 6,215 k Anzahl der Anfragen, eine Zeile basierend auf einer festen Position zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Anfragen ausführen, die erfordern, dass das Ergebnis sortiert wird. Wenn Handler_read_rnd hoch ist, haben Sie wahrscheinlich viele Anfragen, die MySQL zwingen, ganze Tabellen zu scannen, oder Sie haben Joins, die Schlüssel nicht richtig benutzen.
* Handler_read_rnd_next 701 M Anzahl der Anfragen, die nächste Zeile in der Daten-Datei zu lesen. Dieser Wert wird hoch sein, wenn Sie viele Tabellen-Scans durchführen
* Created_tmp_disk_tables 1,245 Anzahl der (implizit) auf der Platte erzeugten temporären Tabellen bei der Ausführung von Statements.
* Select_full_join 16 k Anzahl der Joins ohne Schlüssel. Wenn dieser Wert nicht 0 ist sollten die Indizes der Tabellen sorgfältig überprüft werden.
* Opened_tables 267 Anzahl der Tabellen, die geöffnet wurden. Wenn Opened_tables hoch ist, ist Ihre table_cache-Variable wahrscheinlich zu niedrig.
* Table_locks_waited 908 Wie oft eine Tabellensperre nicht sofort erlangt werden konnte und gewartet werden musste. Wenn dieser Wert hoch ist und Sie Performance-Probleme haben, sollten Sie zunächst Ihre Anfragen optimieren und dann entweder Ihre Tabelle
zerteilen oder Replikation benutzen. -----------------------------
Seltsam finde ich, dass mein alter Hostin plan für 20$ mit gut 70 Leuten gleichzeitig auf der Seite ohne weiteres zu Rande kam, dass aber der neue Server für das 20fache vom Preis schon mit 30 Leuten gleichzeitig Mühe hat und abstürzt. Da kann irgendetwas nicht stimmen.
Ich würde mich sehr freuen, wenn mir jemand weiterhelfen könnte. Denn seit ich den neuen Server habe ist der Traffic massiv gesunken und auch sonst ist es einfach sehr mühsam. Könnte es sein, das es einfach an der Software liegt, die vielleicht schlecht cached und indexiert und darum viele aufwendige Datenbanken Zugriffe macht?
Das angehängte Bild zeigt die Down-/Uptime des Servers (Ein Monitor Skript hat jede Minute versucht auf die Seite zuzugreifen) innerhalb von 48 Stunden. Obere Linie zeigt Uptime, untere Downtime.
Besten Dank,
Michael
MOD: Bitte [noparse]
Code:
...Attachments
Last edited by a moderator: