nicht angemeldet
Server ausgelastet bei 6 Millionen Seitenaufrufen pro Monat?
3 0 
Auge
0 0 1
Server ausgelastet bei 6 Millionen Seitenaufrufen pro Monat?
Hi,
wir haben bei 1&1 einen Managed Server. Über diesen Server laufen etliche Domains. Die Zugriffszahlen sind in den letzten Monaten natürlich gestiegen und wir liegen laut 1&1-Statistik mittlerweile bei gut 6 Millionen Seitenaufrufen (Erfolgreiche Seitenaufrufe. Nicht erfolgreiche oder abgebrochene Aufrufe werden nicht gezählt.) im Monat für alle Domains insgesamt. Seit geraumer Zeit treten sporadisch Fehler auf, z. B. die Domains sind nicht mehr erreichbar oder MySQL schmeißt "too many connections" aus. Dann hilft meist nur ein Anruf bei 1&1 und die starten den Server neu. Bevor ich mich in die 1&1-Warteschlange hänge, frage ich folgendes:
Sind 6 Millionen Seitenaufrufe im Monat viel für einen 4XL64 Quad-Core-Server (die genaueren Server-Daten kenne ich leider nicht, aber soll fett sein *G*)?
Das einzige was wir am Server ändern können ist folgendes
WebDav: aktiv
FastCGI: inaktiv
SSLSupport: aktiv
Einbindung von Perl als CGI-Programm
Einbindung von PHP als CGI-Programm
Speichernutzung: 131072 kB
Prozesslaufzeit: 3600 Sekunden
Anzahl gleichzeitig ausführbarer Prozesse: 1024
Programmordner: /homepages/28/d10xxxxxxxxx/htdocs/executable
Bringt es was, wenn wir die Anzahl der ausführbaren Prozesse erhöhen? Wenn ja, wie viel ist sinnvoll?
Gibt es eine Möglichkeit die Datenbank etwas zu tunen? Ich hab irgendwas von "table cache" gelesen. Der liegt derzeit bei 127. Ist das vielleicht zu wenig?
Vermutlich gibt es auch irgendwelche Flaschenhälse, sei es irgendein Skript oder eine "schlechte" DB-Abfrage. Gibt es da irgendwelche Möglichkeiten/Tools zum Auffinden solcher Flaschenhälse?
Danke und Gruß
-
Hallo Rene,
... MySQL schmeißt "too many connections" aus
dafür gibt es Einstellung (meist in "/etc/my.cnf" oder "/etc/mysql/my.cnf") "max_connections". Die Zahl könnte erhöht werden.
Sind 6 Millionen Seitenaufrufe im Monat viel für einen 4XL64 Quad-Core-Server (die genaueren Server-Daten kenne ich leider nicht, aber soll fett sein *G*)?
Das hängt von der Anwendung ab. Eine schlecht geschriebene Anwendung kann den Server mir 5.000 Besucher/Tag lahm legen.
Bringt es was, wenn wir die Anzahl der ausführbaren Prozesse erhöhen? Wenn ja, wie viel ist sinnvoll?
Das bringt wahrscheinlich nicht viel in dem Fall.
Gibt es eine Möglichkeit die Datenbank etwas zu tunen? Ich hab irgendwas von "table cache" gelesen. Der liegt derzeit bei 127. Ist das vielleicht zu wenig?
Tunen der Datenbank kann man immer machen, wenn man genau weis, was man tut. Bei dem (relativ) großen Traffik hilft ganz bestimmt Optimierung von Anfragen. Dazu gibt es ein Artikel hier:
http://www.zibepla.org/2009/06/15/mysql-wenn-abfragen-langsam-sind/
Vermutlich gibt es auch irgendwelche Flaschenhälse, sei es irgendein Skript oder eine "schlechte" DB-Abfrage. Gibt es da irgendwelche Möglichkeiten/Tools zum Auffinden solcher Flaschenhälse?
Ich würde beobachten (Shell z.B. top -d.5), welche Prozesse die meiste Last verursachen. Ob es "mysql" oder "apache" ist. Wenn man das weis, dann weis man wo man optimieren muss. Bitte ggf. noch mal hier posten.
Gruß Alexander
-
Hallo
Tunen der Datenbank kann man immer machen, wenn man genau weis, was man tut. Bei dem (relativ) großen Traffik hilft ganz bestimmt Optimierung von Anfragen. Dazu gibt es ein Artikel hier:
http://www.zibepla.org/2009/06/15/mysql-wenn-abfragen-langsam-sind/
Huii, da habe ich zwar erstmal eine Schwein-Uhrwerk-Relation, aber das liest sich durchaus interessant. Ab in die Bookmarks, huschhusch!
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
Veranstaltungsdatenbank Vdb 0.3
-
-
Hi,
so pauschal kann man das kaum bestimmen.
Versuch mal munin. Das ist ein System, was ich oft benutze und einem anzeigt, wie und wo der Server belastet ist.Ich tippe allerdings auch in Richtung Datenbank.
Hast Du phpMyAdmin laufen? Dann lass Dir mal die Laufzeitinformationen anzeigen!
Wie sieht Deine /etc/my.cnf aus?Viele Grüße,
Reiner -
Hello,
Sind 6 Millionen Seitenaufrufe im Monat viel für einen 4XL64 Quad-Core-Server (die genaueren Server-Daten kenne ich leider nicht, aber soll fett sein *G*)?
Um das zu beurteilen, müsste man das Logging erst einmal vernünftig einstellen, also beim Apache z.B. sowohl die Bytes vom Request (incl. Uploads), als auch die von der Response (Default) loggen.
Bei Der Datenbank müsste auch entsprechend logged werden... -> binary Log
Aber nicht vergessen: Jede Messung verfälscht das Ergebnis, also jedes Logging belastet den Server zusätzlich.Dann müsste das Verhalten von PHP untersucht werden beim User-Abort. Wird das Script noch zuende ausgeführt, oder wird es einfach abgebrochen, wenn der Client die Antwort nicht mehr vollstänig entgegen nimmt? Bei allen datenverändernden Scripten müsste man als ordentlicher Programmierer eigentlich diese Einstellung (für den datenverändernden Teil) wählen!
Und außerdem könnten wir eine Milchmädchenrechnung aufmachen:
Wenn jeder Seitenaufruf den Server 1 Minute zu 100% in Anspruch nehmen würde (Requests entgegennhemen, Laden der Instanzen, Abarbeitung der Requests, Responses, Aufräumen des Speichers), dann würde dies bedeuten:
60*24*30 = 43200 verfügbare Minuten im Monat => 43200 Aufrufe sind genug, um das Ding platt zu machen
Wenn Du es schaffst, die benötigte Zeit pro Seitenaufruf auf unter 1 Sekunde zu reduzieren (was typisch wahrscheinlich ist), dann kommst Du schon auf
60*60*24*30 = 2.592.000 mögliche Seitenaufrufe/Monat für die Vollauslastung.
Wenn der Host also Server für HTTP, HTTPs, FTP, DBMS und Scripting zur Verfügung stellen muss, dann sind 6.000.000 Seitenbesuche pro Monat schon eine heftig große Zahl, auch für vier Prozessoren.
Übrigens verbessert sich das Verhalten, wenn die Netzanbindung besser wird.
Ggf. sollte man sich für abhängige Requests (Ausliefern von Bildern) einen zweiten Host daneben stellen und dann als nächstes die Datenbankaufgaben ausgliedern.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Moin Moin!
»
Ggf. sollte man sich für abhängige Requests (Ausliefern von Bildern) einen zweiten Host daneben stellen und dann als nächstes die Datenbankaufgaben ausgliedern.
Du meinst unabhängige Requests.
Davon abgesehen würde ich erstmal die DB auf eine andere Maschine verfrachten und beide Maschinen möglichst per Crossover-Kabel miteinander verbinden (lassen). Wenn innerhalb des RZs alles auf Gigabit Ethernet läuft (incl. Switches), kann man auf das Crossover-Kabel auch verzichten.
Wenn auf der Kiste viele Domains laufen, könnte man die auf zwei Maschinen verteilen, sinnvollerweise so, dass die Last ungefähr gerecht verteilt ist.
Caching ist natürlich hilfreich, innerhalb der Applikation z.B. mit memcached.
FastCGI statt CGI ist eine schöne Idee, aber nicht jedes CGI-Script läuft problemlos als FastCGI. CGI ist fire-and-forget, da kann man mit globalen Variablen und diversen Handles rumpfuschen wie man will, am Ende des Requests wird alles automatisch vom Betriebssystem aufgeräumt. Das passiert bei FastCGI nicht.
Die Load Average der Maschine wäre interessant. Im Mittel sollte nicht mehr als ein Prozess pro CPU laufen, bei einem Quad Core sollte die Load Average also nicht wesentlich über 4.0 liegen.
Dienste verteilen ist auch eine Option. Mail, Web, IRC, News, DB, ... müssen nicht auf der selben Maschine laufen.
Vermutlich wird auf der Maschine ein Apache laufen, der kann zwar fast alles, aber es gibt Spezialisten, die in manchen Gebieten schneller und weniger kräftezehrend sind als der Apache. Gerade beim Ausliefern statischer Inhalte ist der Apache nicht der schnellste.
Massives Umschreiben von URLs, dynamisch generiere Inhalte statt statischer Seiten und Techniken wie AJAX können einen Webserver auch ganz gut in die Knie zwingen.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hello,
Ggf. sollte man sich für abhängige Requests (Ausliefern von Bildern) einen zweiten Host daneben stellen und dann als nächstes die Datenbankaufgaben ausgliedern.
Du meinst unabhängige Requests.
Nein, ich meine abhängig im Sinne von: würden nicht stattfinden und wären nicht sinnvoll ohne Request auf die jeweilige Seite.
Z.B. Bilder als vorgefertigte zusätzliche Ressourcen der (berechneten) Page könnte man leicht auslagern auf eine Subdomain, wenn deren Auslieferung nicht an weitere Bedingungen gekoppelt sein soll.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
Hi!
Der 4XL64 Quad-Core-Server kann bei entsprechender Konfiguration durchaus mehrere Hunderttausend statische Requests am Tag bearbeiten. Bei komplexen dynamischen Requests sind es natürlich entsprechend weniger - insbesondere, wenn Datenbank und Webserver auf der gleichen Kiste laufen.
Einbindung von Perl als CGI-Programm
Einbindung von PHP als CGI-ProgrammIch empfehle _unbedingt_ die Verwendung von fastcgi/scgi/mod_php und für PHP entsprechenden XCache. Zudem solltest Du die Scripte, die Du da regelmäßig ausführst, so weit wie möglich optimieren.
Außerdem vermute ich, die Datenbank läßt sich mit vernünftig gesetzten Indexes ohne weiteres noch deutlich optimieren. Das dafür wichtigste Tool ist der gesunde Menschenverstand.
Gruß, LX
--
RFC 1925, Satz 3: Mit ausreichendem Schub fliegen Schweine wunderbar. (...)-
Hi,
Ich empfehle _unbedingt_ die Verwendung von fastcgi/scgi/mod_php und für PHP entsprechenden XCache. Zudem solltest Du die Scripte, die Du da regelmäßig ausführst, so weit wie möglich optimieren.
ja, aber an der Stelle würde ich später weiter optimieren.
Außerdem vermute ich, die Datenbank läßt sich mit vernünftig gesetzten Indexes ohne weiteres noch deutlich optimieren. Das dafür wichtigste Tool ist der gesunde Menschenverstand.
Das ist auch meine Vermutung.
Dazu sollte man sich mal die "slow queries" bzw. Abfragen ohne Indexnutzung auswerfen lassen. Die nimmt man sich dann später mal vor und analysiert die:EXPLAIN ..... select .... from .... where ....
-