Martin Ebert schrieb:
> Dirk, liebe Liste,
>
>
>> Allerdings gibts eine nicht unerhebliche Differenz zwischen dem
>> Skript-Processing und den Response-Times.
>>
>
> Ich lese den thread mit belustigter Verwirrung mit.
> Da ich php für Teufelskram halte kann ich dazu auch
> nichts sagen.
>
> Aber vielleicht müssen wir zu den Wurzeln zurück:
> load=30 ist hammerhart. load=3 würde ich schon für
> extrem kritisch halten:
> Da warten bei load=30 also 30 Prozesse im Scheduler
> dass die auch mal drankommen dürfen. Und das sind
> wohl genau die Prozesse, die mit "write" beim Apache
> rumstehen.
> Ich versteige mich zu der Aussage, dass das Ziel
> load < 1 ist.
>
Absolut richtig. Wobei erfahrungsgemäß auch eine Load von 5 noch als
"schnell" aufgefasste Antwortzeiten erzeugt.
Aber ja - 30 ist natürlich definitiv zu hoch. Daher u.A. (!!!) auch die
Suche nach möglichen Flaschenhälsen beim Apachen.
> Irgendwo ist also ein _extremer_ Flaschenhals. Und der
> Teufel namens php kann das ja nun kaum sein.
>
Doch - klar kann es. Überhaupt keine Frage. Nur steht in diesem Fall
etwas anderes als php voerst nicht zur Disposition.
Besser Code birgt sicher ein erhebliches Potential. Es ging mir aber wie
gesagt hier nicht um Code-Optimierung, sonder darum, wie ich
von Apache-Seite noch weiter unterstützen kann, bzw. warum da Prozesse
solange im Status "W" hängen. Inzwischen weiß ich das dies halt
nicht nur das senden des fertig geparten Inhaltes beinhaltet - sondern
auch das processing.
> Was haben wir als Verdächtige?
>
> * CPU
> ** wohl kaum. Die hätte schon abgekackt.
>
> * Bandbreite gen Web. Das wäre wirklich ein
> Verdächtiger. Aber das erklärt nicht, warum das
> mit steigenden Requests steigt. Passt auch nicht.
>
> * Bus-Breite gegen Plattenstrecke.
> Ich habe mehrfach die Beobachtung gemacht, dass
> Apache extrem nicklig ist, wenn er nix bekommt oder
> nix wegschreiben kann. Dann steigt die load schnell
> in extreme Größen.
> Und das ist mein Verdacht beim Mitlesen.
>
Wie gesagt - laut vmstat gibt es keine IO-Latenzen. Und ja - es ist ein
2.6er Kernel. :)
> Rein analythisch: Was haben wir da so?
> * die mysql-Datenbank selbst: Liefert die schnell genug?
>
Die DB ist wie beschrieben außen vor - da zum Zeitpunkt der
beschriebenen Problemen quasi vor sich hin schlafen - weil keine Queries
mehr von den Apachen eintreffen.
Die Verbindung zwischen den Hosts ist eine 1MBit Strecke im gleichen
Rack mit eigenen Switch zw. Webservern und DB-Servern. Die Webtraffic
läuft nicht darüber.
> * das interne Netz: Bounct da was?
> IRGENDWAS, was da falsch geroutet wird?
> * die eigene Plattenstrecke: Alle Platten ok?
>
Ja - Betriebssystem und preventiver Austausch der Platten bestätigen das.
> Ok,
> nun lehne ich mich ganz weit aus dem Fenster:
> 10 Euro als Wette auf den Tisch!
> Dein Apache bekommt die Logs nicht weggeschrieben.
> Du hast ein Problem mit der Plattenstecke in dem
> Rechner, in dem Apache läuft. Wette ich jetzt mal.
>
:) Die 10 Euro hätte ich gewonnen. Die logs sind größtenteils
deaktiviert (oft nur zu evaluations-zwecken aktiv),
oder wenig beschrieben. Access-Log läuft nicht mit - Error-Log ist
unwesentlich genutzt - nicht relevantes - hier und da mal eine
fehlende Ressource (image - falsche ingebene URL etc...)
> Mit freundlichen Gruessen, Martin Ebert
>
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
