performance killer bei php5-fastcgi/lighttpd finden

[me-myself-and-i]

Hi,

ich war der glückliche aus diesem thread ... eigentlich.

neuerdings bricht die kiste ein und die seite ist etwas "langsam" und der lighttpd liefert nen 500ter.

im logfile vom lighty findet sich folgendes

2006-08-10 14:33:28: (connections.c.1396) returning the original status 404
2006-08-10 14:33:28: (connections.c.1398) If this is a rails app: check your production.log
2006-08-10 14:33:28: (connections.c.1394) Warning: Either the error-handler returned status 404 or the error-handler itself was not found: /index.php?error=404

bzw

2006-08-10 08:35:23: (mod_fastcgi.c.3457) all handlers for /index.php on .php are down.
2006-08-10 08:35:26: (mod_fastcgi.c.2599) fcgi-server re-enabled: 0 /var/www/fastcgi/web3/web3.socket
2006-08-10 08:35:31: (mod_fastcgi.c.2821) backend is overloaded, we disable it for a 2 seconds and send the request to another back
end instead: reconnects: 0 load: 138

Ich habe mich dann via strace an einen der fastcgi php gehangen und so schon einmal rausgefunden das es durch eines dieser unsäglichen wordpress plugins einen loop gegeben hat ... das plugin rausgeworfen, alle spuren beseitigt (inkl Datenbank), aber es war leider nicht der grund.

aber mir ist aufgefallen das sehr viele calls wie folgt enden (oder ähnlich)

Code: Select all

write(7, "270\0\0\03SELECT DISTINCT MONTH(post_"..., 188) = 188
read(7, "1\0\01", 4)                  = 4
read(7, "2", 1)                        = 1
read(7, " \0\02", 4)                   = 4
read(7, "3def\0\0\05month5monthf?\02\0\0\010\0200\0\0\0", 32) = 32
read(7, "36\0\03", 4)                 = 4
read(7, "3def\0\0\04year4yearf?\04\0\0\010\0200\0\0\0", 30) = 30
read(7, "5\0\04", 4)                  = 4
read(7, "376\0\02\0", 5)              = 5
read(7, "7\0\05", 4)                  = 4
read(7, "\0017\0042006", 7)             = 7
read(7, "5\0\06", 4)                  = 4
read(7, "376\0\02\0", 5)              = 5
fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
read(7, 0x86ba1e8, 8192)                = -1 EAGAIN (Resource temporarily unavailable)
fcntl64(7, F_SETFL, O_RDWR)             = 0

oder noch einmal besser sichtbar

Code: Select all

rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
read(7, 0x86b4790, 8192)                = -1 EAGAIN (Resource temporarily unavailable)

Das Problem was sich mir jetzt stellt was verursacht die probleme und "hänger"... an dem drunterliegenden System hat sich nichts geändert. Ich vermute aber das hier etwas im verarbeiten schief läuft. Vor allem laufen zeitgleich die anderen vhosts auf dem Server ohne probleme und ohne performance probleme.

Heute Abend werde ich sowohl Datenbank als auch Web auf einen Stand von vor zwei Tagen setzen in der Hoffnung das es hilft. Da es eigentlich (meiner Ansicht nach) nur an den Applikationen liegen kann. Aber vielleicht kann mir jemand von euch noch einen Hint geben in welche Richtung die suche gehen kann, bzw gehen sollte...

Danke.

[braindead]

Hi, ich hatte dir damals schon eine paar Webseiten mit Tipps zum Wordpresstuning genannt. Hast du dir die mal angeguckt? Vielleicht hilfts ja....

[me-myself-and-i]

sorry, das hatte ich vergessen zu schreiben ...

wp-cache ist eingebaut ... apc ja sowieso ...

.. heute abend geht es mit viel cola wieder ans debuggen ... nehme an das es ein Problem beim Wordpress ist, kann es aber nicht verifizieren ... vor allem aber muss es gerade gebogen werden ... ist blöde wenn das bildblog offline ist :/

[Roger Wilco]

nehme an das es ein Problem beim Wordpress ist, kann es aber nicht verifizieren

Wäre auch mein erster Tipp. Wie wärs mit einer richtigen Software? *hust*s9y*hust*
Das Slow-Query Log könnte auch Hinweise auf Flaschenhälse/häufige Abfragen geben.

vor allem aber muss es gerade gebogen werden ... ist blöde wenn das bildblog offline ist :/

<southpark>Ihr habt das BildBlog getötet! Ihr Schweine!</southpark>
Wie sieht deine lighttpd.conf bzw. dein Setup derzeit aus? Hast du mal mit dem Idle Timout von mod_fastcgi rumgespielt? Erstellst du die PHP-Prozesse selbst (spawn-fcgi) oder lässt du das von lighttpd machen?

[me-myself-and-i]

alles noch genauso wie in diesem thread ....


slow log ist nichts vorhanden ... leider, sonst hätte ich ja was zum suchen.

das system habe ich nicht ausgesucht, es ist halt "gewachsen" ... gerade im jetzigen zustand ist auch die migration etwas schwerer, vor allem weil sich derjenige welcher sich eigentlich um die applikation kümmern, jetzt gerade mit wordpress klar kommt ... ^^

gnah, warum habe ich nur gesagt das ich helfe ...

ok, also ich spawn die fastcgi prozesse extern, eben für die performance, es ist der im wiki vorgeschlagene weg... eben wie es auch im oben genannten posting sozusagen "ausgearbeitet" wurde.

beim stracen ist mir halt aufgefallen das die prozesse sich verabschieden ... aber es scheint der php interpreter zu sein, nur ohne fehlermeldung, was dazu führt das bei reichlich anfragen fast alle prozesse im "handle-request" beschäftigt sind.

ich hoffe das es nachher mit dem einspielen der alten datenbank und dem restore der webdirs alles wieder läuft...

[me-myself-and-i]

ok wordpress ist S')($$§§&"$&/"§$

Wenn ein Plugin deinstalliert wird, bleiben die Spuren in der Datenbank zurück stellenweise auch im Code ... Optionen bleiben aktiviert oder funktionen werden noch augerufen usw ...

Nach einspielen des Backups lief es dann alles wieder ... nur das die aktuellen inhalte natürlich noch in der alten DB sind ... aber wofür haben die Jungs den eine Entwicklungs und Testumgebung ? ... stimmt eigentlich sollten Plugins da vorher mal getestet werden, aber sowas machen wir lieber am offenen Herzen ... immer diese hobbyisten ...

Jetzt kann/muss/darf ich mich in einer "gesicherten" Umgebung hinsetzen und das ganze Debuggen um dann entweder den/dem die/der UltimateTagWarrior oder Wordpress verbrochen hat ... ach lassen wir das ... wenn ich lust und Zeit habe werde ich das zusammenspiel zwischen Lighty und dem utw mir mal genauer anschauen und kann nur jedem Lighty/Wordpress benutzer davon abraten ...

Sorry für die verschwendete Zeit...
j

ps: achja case closed

[oxygen]

Oft sind Plugins/Module/Hacks/Addons/whatever für Webanwendungen ziemlich schlampig programmiert und verursachen damit Performance Probleme oder gar Sicherheitslücken. Gerade auch bei phpbb ein großes Problem.