nicht angemeldet
Böse Überraschung beim Launch der Seite
Hallo,
heute haben wir die neue Version unserer Community emopunk.net gestartet und schon 10 Minuten nach dem Start ging garnichts mehr. Der Server total Überlastet, nur noch Internal Server Error 500.
Zwischenzeitlich haben wir dann die maximal ausführbaren Prozesse des Servers von 500 auf 1000 (max. 1024) erhöht - es gab dann zwar nicht mehr soviele 500er aber die Seite blieb unbenutzbar langsam.
Nun ist Ursachenforschung angesagt, um das Problem schnell zu beheben.
Die erste Version der Seite lief zwar nie richtig schnell, aber kam mit 100 Leuten gleichzeitig Online und bis zu 8.000 Besuchern täglich ganz gut zurecht.
Ich war der Meinung wir hätten die ganze Sache jetzt viel effizienter gestaltet, zumindest das Datenbankdesign - und es kamen ja auch keine Datenbankfehler sondern ISE-500.
Gravierende Unterschiede zu früher: SessionManagemant nicht mehr Standard über Files sondern über die Datenbank und viel mehr PHP-includes, da viele dinge an mehreren Stellen verwendet werden können.
Treibt das vielleicht die Prozesse in die Höhe?
Was sind noch häufug gemachte Fehler, die den 500er Error erzeugen?
-
Hallo,
Was sind noch häufug gemachte Fehler, die den 500er Error erzeugen?
a) schlecht Programmmiert d.h. schlicht fehlerhafter Code.
b) die Scripte im falschen FTP-Modus (binary statt ASCII) hochgeladen.Grüße
Thomas-
你好 Thomas,
b) die Scripte im falschen FTP-Modus (binary statt ASCII) hochgeladen.
Das gilt fuer PHP nicht.
再见,
CK
-
-
Hi,
heute haben wir die neue Version unserer Community emopunk.net gestartet und schon 10 Minuten nach dem Start ging garnichts mehr. Der Server total Überlastet, nur noch Internal Server Error 500.
Es gibt die verschiedensten Fehleranzeigemethoden, die da etwas geschwätziger sind als so ein nichtssagender 500er, bitte baue sie ein.
Die erste Version der Seite lief zwar nie richtig schnell, aber kam mit 100 Leuten gleichzeitig Online und bis zu 8.000 Besuchern täglich ganz gut zurecht.
Und warum wurde das dann geändert?
Ich war der Meinung wir hätten die ganze Sache jetzt viel effizienter gestaltet, zumindest das Datenbankdesign - und es kamen ja auch keine Datenbankfehler sondern ISE-500.
Das können auch Datenbankfehler sein, aber ohne zischengeschaltete Fehlermeldungsroutinen kann man das nicht sagen. So ganz ohne Code natürlich auch nicht.
Gravierende Unterschiede zu früher: SessionManagemant nicht mehr Standard über Files sondern über die Datenbank und viel mehr PHP-includes, da viele dinge an mehreren Stellen verwendet werden können.
Es ist zwar nicht unbedingt Geschwindigkeitssteigernd alles klein-klein zu machen aber der Grund dürfte wohl in der Datenbankbenutzung liegen:
Jede, ich wiederhole: _jede_ Datenbankanfrage ist richtig teuer, da braucht's verdammt viel PHP-Code, das auch nur ansatzweise auszugleichen.Das ist die einzige Vermutung, die ich ohne weitere Details abzugeben wage und setzt auch vorraus, das der Rest wirklich in Ordnung ist. Aber ich möchte mich da eigentlich auch an Thomas' Vermutung anschließen: es ist wahrscheinlich irgendwo ein ganz blöder Programmierfehler drin.
so short
Christoph Zurnieden
-
ok... gut gut.
also die sql-abfragen sind jetzt bestimmt weniger und effizienter.
solange wenige leute gleichzeitig die seite nutzen, gibt es ja auch gar keine fehler...
zu fehlern kommt es, wenn die gleichzeitig erlaubten prozesse des servers nicht mehr ausreichen sprich wenn viele Leute online sind.
die Lösung ist also: es darf nicht zu so vielen prozessen auf einmal kommen.fragen wir mal so: was genau bezeichnet ein prozess bzw. was löst einen (neuen) aus?
ein script ein prozess? eine funktion ein prozess? eine db abfrage ein prozess? ein include ein prozess? oder alles oder nichts? oder viel komplexer?
-
Hi,
also die sql-abfragen sind jetzt bestimmt weniger und effizienter.
Du gibst absolut keine Details raus und echauffierst Dich dann darüber, das man ein klein wenig aus dem Schatzkästlein plaudert, aber im Grunde doch nur in's Blaue rät - ja, nur raten kann?
solange wenige leute gleichzeitig die seite nutzen, gibt es ja auch gar keine fehler...
Nein, dann gibt es keine Fehler_meldung_, das ist ein wichtiger Unterschied! Ich habe gesagt, was zu tun ist, damit man herausbekommt woran es liegen könnte, was hast Du davon probiert?
zu fehlern kommt es, wenn die gleichzeitig erlaubten prozesse des servers nicht mehr ausreichen sprich wenn viele Leute online sind.
die Lösung ist also: es darf nicht zu so vielen prozessen auf einmal kommen.Nö, die Lösung ist weniger Leute dran zu lassen >;->
fragen wir mal so: was genau bezeichnet ein prozess bzw. was löst einen (neuen) aus?
Ohne nähere Angaben kann Dir das keiner sagen.
ein script ein prozess? eine funktion ein prozess? eine db abfrage ein prozess? ein include ein prozess? oder alles oder nichts? oder viel komplexer?
Keine Ahnung, kann alles möglich sein.
Also:
Welches Betriebsystem wird verwand.Wie ist eure Maschine aufgebaut:
- Apache und PHP und MySQL? Welche Versionen?
- Sonstiges? In welchen Versionen?
Was ist mit dem PHP-Code, kann man den irgendwo bewundern?
Nehmt ihr da Code von Drittanbietern und wenn ja: welchen in welcher Version?Und ganz wichtig: gibt es trotz aller eingeschalteter Debugging-Meldungen gar keine andere Fehlermeldung? Was sagt das Log?
Was ist mit den Schleifen: haben die auch alle eine Abbruchbedingung? Wirklich _alle_? Nein, schau nach!
Sind das eigentlich wirklich Prozesse (fork())? Wieviele Threads pro Prozess?
so short
Christoph Zurnieden
-
Du gibst absolut keine Details raus und echauffierst Dich dann darüber, das man ein klein wenig aus dem Schatzkästlein plaudert, aber im Grunde doch nur in's Blaue rät - ja, nur raten kann?
sorry, bin ein wenig fertig mit den nerven gerade... also ein par mehr infos:
Datenbanken: statt bei jedem klick aus ner tabelle von 100.000 privaten nachrichten die anzahl der eigenen zu zählen (wie früher), wird bei einer neuen nachricht an ein communitymitglied eine feste anzahl inkrementiert und gespeichert. nach diesem prinzip werden auch posts und threads in forum immer fest gespeichert. spart also ständiges durchzählen. Ansonsten sind nachrichten, forum und user tabellen so wie früher - was mich dazu bringt zu sagen, es ist effizienter.Nein, dann gibt es keine Fehler_meldung_, das ist ein wichtiger Unterschied! Ich habe gesagt, was zu tun ist, damit man herausbekommt woran es liegen könnte, was hast Du davon probiert?
zugegeben, bisher nichts - wenn du mir nochmal kurz erleutern könntest welche fehlermeldungs-geschichten man in php einbauen kann, versuch ich das.
Keine Ahnung, kann alles möglich sein.
Also:
Welches Betriebsystem wird verwand.
Wie ist eure Maschine aufgebaut:hier die phpinfo: www.emopunk.net/info.php solltest du alles drin finden
Und ganz wichtig: gibt es trotz aller eingeschalteter Debugging-Meldungen gar keine andere Fehlermeldung? Was sagt das Log?
muss ich noch gucken, wo find ich sowas?
Was ist mit den Schleifen: haben die auch alle eine Abbruchbedingung? Wirklich _alle_? Nein, schau nach!
ja!
Sind das eigentlich wirklich Prozesse (fork())? Wieviele Threads pro Prozess?
tja von sowas hab ich keine ahnung... wenn du mir das erleutern könntest
-
你好 rainer,
Keine Ahnung, kann alles möglich sein.
Also:
Welches Betriebsystem wird verwand.
Wie ist eure Maschine aufgebaut:hier die phpinfo: www.emopunk.net/info.php solltest du alles drin finden
Server API: CGI
Damit steht fest, bei jedem Request auf eine PHP-Datei wird ein (ziemlich
grosser) Prozess gestartet (naemlich der PHP-Interpreter).Ansonsten solltest du vielleicht mal den Apache updaten, in der Version
1.3.29 sind einige sicherheitsrelevante Bugs.再见,
CK-
Ansonsten solltest du vielleicht mal den Apache updaten, in der Version
1.3.29 sind einige sicherheitsrelevante Bugs.ist ein management server von 1und1, da kann ich leider nix updaten... für en root kenn ich mich viel zu wenig aus.
Laut support ist mit hard und software alle in ordnung und auf bestmöglichste performance eingestellt... aber sie werden bestimmt nicht sagen, das es nicht in ordnung ist oder bugs hat-
你好 rainer,
Laut support ist mit hard und software alle in ordnung und auf
bestmöglichste performance eingestellt...lol, also, sorry, aber ich wuerde mir schnellstens jemanden suchen, der das
richtig[tm] macht. PHP im CGI-Modus ist mit _Sicherheit_ nicht die
bestmoegliche Performance.再见,
CK-
hier mal ein par bildchen, was da heute abgegangen ist:
www.emopunk.net/log.html
-
richtig[tm] macht. PHP im CGI-Modus ist mit _Sicherheit_ nicht die bestmoegliche Performance.
hmm... eine option kann ich einstellen: php-modul an[], aus[x] zur zeit aus sonst noch Perl als Apache-Modul, fastCGI und webDAV, aber das hat ja wohl nichts damit zu tun, aber was ist mit dem php-modul?
-
你好 rainer,
richtig[tm] macht. PHP im CGI-Modus ist mit _Sicherheit_ nicht die
bestmoegliche Performance.hmm... eine option kann ich einstellen: php-modul an[], aus[x] zur zeit
ausDas solltest du vielleicht ein schalten. Das loest nicht dein Problem (das
duerfte woanders gelagert sein), aber was das angeht brauchen wir zwingend
das error-log.再见,
CK-
Das solltest du vielleicht ein schalten. Das loest nicht dein Problem (das
duerfte woanders gelagert sein), aber was das angeht brauchen wir zwingend
das error-log.also ich denke auch nicht das es (nur) daran liegt - denn wie gesagt, die alte website hat ja alle besucher geschafft, aber kanns ja mal einschalten.
ja das error log - weiß nicht genau wo das liegt, aber hab grad eh kein ssh zugang - warum auch immer -
ich probiers dann morgen einfach nochmal und frag hier dann vielleicht nochmal nach.aber erstmal vielen dank für die hinweise
-
-
Hi,
da ist man mal ein Stündchen weg ... ;-)
richtig[tm] macht. PHP im CGI-Modus ist mit _Sicherheit_ nicht die bestmoegliche Performance.
Na, _das_ ist aber mal wirklich WorstCase, wer kommt denn auch solche Ideen? 1&1? *sigh*
hmm... eine option kann ich einstellen: php-modul an[], aus[x] zur zeit aus sonst noch Perl als Apache-Modul, fastCGI und webDAV, aber das hat ja wohl nichts damit zu tun, aber was ist mit dem php-modul?
Was sagt denn die Hilfe zu dem Punkt? >;->
Aber die schlechten Scherze mal beiseite: probiere es einfach mal aus, viel passieren kann da nicht. (Aber denk an die Pferde und die Apothekenbürgersteige!)
Vielleicht ist es sogar der richtige Schalter? Würde mich aber wundern und wie ich gerade sehe bin ich da wohl auch nicht der einzige.so short
Crhistoph Zurnieden
-
-
-
Moin,
»» ist ein management server von 1und1,
Sollte sich herausstellen, dass es am Server bzw. seiner Konfiguration liegt, schau mal bei incoWeb vorbei. Die hosten zB auch OS Community (max. Userzahl gleichzeitig: 1100).
Grüße aus Hamburg
Michel--
Ein Problem ist halb gelöst, wenn es klar formuliert ist. (John Dewey)
-
-
-
Hello,
Datenbanken: statt bei jedem klick aus ner tabelle von 100.000 privaten nachrichten die anzahl der eigenen zu zählen (wie früher), wird bei einer neuen nachricht an ein communitymitglied eine feste anzahl inkrementiert und gespeichert. nach diesem prinzip werden auch posts und threads in forum immer fest gespeichert. spart also ständiges durchzählen. Ansonsten sind nachrichten, forum und user tabellen so wie früher - was mich dazu bringt zu sagen, es ist effizienter.
Wurden denn die zusammengehörigen Statements gebunden?
entweder
- Transaktion-Control
oder
- Locking?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
-
-
Moin!
Zwischenzeitlich haben wir dann die maximal ausführbaren Prozesse des Servers von 500 auf 1000 (max. 1024) erhöht - es gab dann zwar nicht mehr soviele 500er aber die Seite blieb unbenutzbar langsam.
Allein das ist doch schon ein Alarmzeichen. Die Zahl paralleler Prozesse kann zwar bei wirklich extrem gut besuchten Seiten schon mal so groß werden, dann braucht es aber tatsächlich eine wirklich leistungsstarke Maschine. Abgesehen davon bedeuten 1000 parallele Prozesse natürlich auch tausend gleichzeitige Zugriffe. Selbst wenn man davon ausgeht, dass eine durchschnittliche Seite mit HTTP/1.1-Browser vielleicht zehn gleichzeitige Verbindungen aufbaut, sind das immer noch 100 zeitgleiche User - eine Zahl, die definitiv sehr hoch ist.
Die erste Version der Seite lief zwar nie richtig schnell, aber kam mit 100 Leuten gleichzeitig Online und bis zu 8.000 Besuchern täglich ganz gut zurecht.
Hundert Leute gleichzeitig laden aber niemals im Sekundentakt alle parallel eine neue Seite herunter. Wenn je User zehn Prozesse auf dem Server laufen, also hundert verschiedene User je Zeitpunkt aktiv sind, dann deutet die Vollauslastung tendentiell auf etwa 3000 gleichzeitige User hin, sofern wir mal annehmen, dass alle 30 Sekunden jemand eine Seite neu lädt und der Prozess dafür eine Sekunde CPU-Zeit benötigt.
Ich war der Meinung wir hätten die ganze Sache jetzt viel effizienter gestaltet, zumindest das Datenbankdesign - und es kamen ja auch keine Datenbankfehler sondern ISE-500.
Ist die Datenbank denn so konfiguriert, dass sie ihrerseits 1000 gleichzeitige Verbindungen von den PHP-Skripten akzeptiert? Wenn nicht, dann herrscht logischerweise ein Ungleichgewicht. Und du solltest dann die Anzahl der Apache-Prozesse lieber von 500 absenken auf z.B. 100 oder 200, und analog dazu die Zahl der gleichzeitigen DB-Verbindungen setzen. Denn sonst warten sich die PHP-Skripte zu Tode, weil keine DB-Verbindung frei ist.
Gravierende Unterschiede zu früher: SessionManagemant nicht mehr Standard über Files sondern über die Datenbank und viel mehr PHP-includes, da viele dinge an mehreren Stellen verwendet werden können.
Das ist wahrscheinlich mit ein Grund für die Überlastung, denn das Session-Management greift natürlich ständig auf die DB zu, während die Speicherung in Dateien "nur" die Festplatte belastet - und außerdem passiert bei der Sessiondatenspeicherung eigentlich nichts, was eine Datenbank zwingend erfordern würde, außer du hast irgendwelche spannenden Sachen eingebaut, von denen du hier noch nicht erzählt hast.
Was sind noch häufug gemachte Fehler, die den 500er Error erzeugen?
500-Fehler ist sowas von nichtssagend. Schau in dein Error-Logfile rein, woran es liegt. Irgendwas geht ja schief, der Status 500 sagt das, aber leider sagt er nicht, WAS schief geht. Und wenn du analysiert hast, wo das Problem liegt, kannst du es auch beheben.
- Sven Rautenberg
-
Hello,
Server: ?
verwendete Sprache: PHP
Datenbank: ?
fertige Module: ?
fertige Klassen: ?
Flatfiles: ?
Clienting: ?
Adminsitration durch User: ?
...Ich sag mal: Du gibst uns leider zuwenig Infos.
Ich tippe mal ganz blind auf zwei beliebte Fehler:
- Falsche Locking-Strategie
- Lost Handles
-- bei Flatfiles
-- bei der Datenbank
Das führt ggf. zu Deadlocks und Memory-Mangel
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
hier alle infos:
www.emopunk.net/phpinfo.php
-
Hello,
hier alle infos:
www.emopunk.net/phpinfo.phpWo?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
versuchs jetzt nochmal, war eben noch nicht oben... die phpinfo() ausgabe ist doch ausreichend für php, apache, mysql version und so?!
-
Hello,
versuchs jetzt nochmal, war eben noch nicht oben... die phpinfo() ausgabe ist doch ausreichend für php, apache, mysql version und so?!
Die kam doch eben schon.
Leider sagt die Infoausgabe nichts darüber aus, ob eine DB genutzt wird und welche, welche fertigen Klassen eingebunden wurden, ob mit Flatfiles gearbeitet wird, etc...Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
Leider sagt die Infoausgabe nichts darüber aus, ob eine DB genutzt wird und welche, welche fertigen Klassen eingebunden wurden, ob mit Flatfiles gearbeitet wird, etc...
DB: mysql
- was sind flatfiles?
-
Hello,
Leider sagt die Infoausgabe nichts darüber aus, ob eine DB genutzt wird und welche, welche fertigen Klassen eingebunden wurden, ob mit Flatfiles gearbeitet wird, etc...
DB: mysql
- was sind flatfiles?
Ganz normale Dateien, die man sich mit PHP selber so zurechtbiegt, wie man sie benötigt...
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau-
Hallo,
- was sind flatfiles?
Ganz normale Dateien, die man sich mit PHP selber so zurechtbiegt, wie man sie benötigt...
kannst du das etwas genauer erklären?
oder hast du eine deutsche Erklärung irgendwo zur Hand?mfg
Twilo-
Hallo Twilo!
[...] flatfiles?
kannst du das etwas genauer erklären?
oder hast du eine deutsche Erklärung irgendwo zur Hand?Ich nehme an, Tom würde Dich in seinem nächsten Posting auf PHP: Experimentelle Sammlung von Flat-File-Funktionen verweisen.
Die Datei ist, so wie ich das auf den ersten Blick gesehen hab, recht brauchbar dokumentiert.Grundsätzlich sind Flatfiles einfache Textdateien.
In diesen speicherst Du Deine Daten, und diese veränderst Du dann mittels geeigneter Funktionen. Eben eine "Datenbank" auf Textdatei-Basis.Ist jetzt vielleicht nicht hundertprozentig korrekt, aber ich hoffe verständlich ;)
MfG
Götz--
Losung für Freitag, 14. Januar 2005
Ich glaube aber doch, dass ich sehen werde die Güte des Herrn im Lande der Lebendigen. (Psalm 27,13)
Jesus sprach: Siehe, das Reich Gottes ist mitten unter euch. (Lukas 17,21)
(Losungslink)-
Hi Götz,
Ich nehme an, Tom würde Dich in seinem nächsten Posting auf PHP: Experimentelle Sammlung von Flat-File-Funktionen verweisen.
hehe ;-)
Ja, man kann es eigentlich ganz gut dazu gebrauchen, Datensätze in Textdateien (oder richtig: Flatfiles) zu speichern.
kleiner Nachteil: Wenn dass Zeug performant werden soll, dann kannst du es eigentlich nur über die ID des Datensatzes aufrufen, so einfach wie bei SQL mit WHERE x = y gehts eider nicht.
Die Datei ist, so wie ich das auf den ersten Blick gesehen hab, recht brauchbar dokumentiert.
Joah, ursprünglich wollten wir da auch mal noch einen Feature Artikel dazu schreiben, kA ob daraus noch was wird, wir sind i.M. glaube ich beide recht beschäftigt ;-)
MfG, Dennis.
--
Mein SelfCode: ie:{ fl:{ br:^ va:) ls:< fo:) rl:( n4:& ss:) de:> js:( ch:{ sh:( mo:} zu:|
Zufällige Hinweise:
------------------------
Meine Homepage: http://www.riehle-web.com
Tutorial: http://tutorial.riehle-web.com-
Hello,
Joah, ursprünglich wollten wir da auch mal noch einen Feature Artikel dazu schreiben, kA ob daraus noch was wird, wir sind i.M. glaube ich beide recht beschäftigt ;-)
So sieht es aus. Einerseits ja 'gottseidank'...
Aber die andere Variante (siehe 'Adressverwaltung') gehört ja auch dazu.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
-
-
-
-
-
Hi,
wir hatten mal da gleiche Problem in meinen Praktikummit einen ASP Server. Solange wir offline testeten, ging es, online nicht.
Wir haben dann bei unseren testserver (offline) die Timeouts stark runtergesetzt (teilweise 2 Sekunden) und die Windows Auslastungsgraphik aufgerufen und ständig angezeigt.Sobald nun eine Seite aufgerufen wurde, konnten wir sehen, ob diese viel ressourcen braucht oder nicht. So war dann die Fehlersuche einfacher.
Was bei uns viel gebracht hat:- includes erstellen
- css files auf jedem Server speichern (vorher waren die auf anderen Domainen, das dauerte)
- SqlBefehle überarbeiten und weniger Schleifen verwenden.
- Bei der Abfrage der Daten gleich eine Beschränkung der Datenmenege eingeben (z.b: nur die ersten 200 Sätze) und dies dann nicht über Skript wieder aussortieren
- Datenbank Verbindungen am ende der Datei schliessen (mus sman das auch in PHP?)
So, ich hoffe, ich konnte etwas helfen,
Schöne Grüsse
Stefan