Apache: manchmal Workers am Limit

[whisper]

Wie ihr wohl wisst, betreibe ich gemeinsam mit Freunden einen Rootserver.
Als Monitoring Tool verwende ich netdata.
Nun war mir aufgefallen, dass manchmal die Apache Workers am Limit von 150 sind. Das Resultat: dann ist der Apache gefühlt eingeschlafen und man wartet, bis man eine Antwort bekommt und sich die Seiten aufbauen.
Nun habe ich gestern das Workers Limit auf MaxRequestWorkers 250 gesetzt.
(/etc/apache2/mods-available/mpm_prefork.conf)
Nun ist eigentlich alles genauso, nur das Limit 250 wird auch gerissen.
Wenn ich mir den Rest der Statistiken ansehen finde ich nicht die Ursache.

Sicherung ist gegen 4 Uhr, aber eigentlich nicht zu erklären. Der Peak um 7:20 Uhr ist mir nicht zu erklären.
Ideen?
Mit den Extrafunktionen von netdata habe ich bereits rumgefummelt, bin aber wohl zu blind, das richtig zu nutzen.
Mein Server ist ein bookworm.

[debilian]

da wäre die Ausgabe von "top" und htop" interessant,
eventuell dann noch "netstat" mit Optionen.
bzw. halt die Specs vom Server; CPU, RAM, Festplatten.

[whisper]

Danke dir.
Das System hat genug power.
Ich könnte auch 1000 workers einstellen, bin aber ziemlich sicher, dass dann die auch für gewisse Zeit am Limit sind.
In den Logs ist nichts zu sehen, das hätte ich auch vermutlich in netdata sehen können.
Aber um deine Neugier zu befriedigen:
Server steht bei Hetzner, entspricht in etwa dem hier fürs Forum, was Zufall ist.

Code: Alles auswählen

CPU:
  Info: 6-core model: AMD Ryzen 5 3600 bits: 64 type: MT MCP cache: L2: 3 MiB
  
  free -h
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       62Gi        16Gi       7,6Gi       812Mi        40Gi        46Gi
Swap:           31Gi       247Mi        31Gi

load average: 2,78, 2,95, 3,04
  

habe mal 1000 Worker eingestellt, mal beobachten, ob das wie vermutet auch erreicht wird.

[debilian]

load average: 2,78, 2,95, 3,04

also die Load würde mir Sorgen machen, da stimmt, imho, irgendwas nicht,
guck mal, was mein Server mit ca. 50 Webseiten/Datenbanken und 200 Emailadressen macht:

Code: Alles auswählen

top - 11:30:26 up 20 days,  3:00,  1 user,  load average: 0,15, 0,18, 0,18
Tasks: 265 total,   1 running, 264 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0,0 us,  0,3 sy,  0,0 ni, 99,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  :  0,3 us,  0,7 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu2  :  0,7 us,  0,3 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu3  :  0,7 us,  1,3 sy,  0,0 ni, 98,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   7978,0 total,   1078,7 free,   4092,1 used,   2807,1 buff/cache
MiB Swap:    976,0 total,      0,0 free,    976,0 used.   2583,7 avail Mem

Code: Alles auswählen

MaxRequestWorkers         150

[whisper]

Ich habe 6 cores und 12, wenn du die virtuellen mit zählst.
U.a. läuft ein confluence mit tomcat, was viele Besucher aus den Staaten hat, da ist schon mal der Bär los. Das ist nicht die Ursache.
Normalerweise ist der load unter 3
Übrigens 1000 worker gehen gar nicht

Code: Alles auswählen

AH00181: MaxRequestWorkers of 1000 exceeds ServerLimit value of 256, decreasing to match

Also 256, na mal sehen

[homer65]

Hallo Whisper,
hast Du schon mal https://github.com/javamelody/javamelody ausprobiert?
Ich habe das zwar noch nicht gemacht, aber schon mal damit geliebäugelt.
Installation scheint einfach zu sein. Wie die Ergebnisse sind weiss ich noch nicht.
Werd es aber mal versuchen.
Gruß Christian
Edit:
Habs soeben ausprobiert. Lies sich anhand des User Guide in 5 Minuten installieren.

Habe mir jetzt mal die Ergebnisse angeschaut. Interessant finde ich den Punkt "Details" bei "Statistiken für http - 1 Tag seit Mitternacht".
Da sieht man genau bei welcher Unterseite wie viel Zeit verbraucht wird.

[MSfree]

Code: Alles auswählen

AH00181: MaxRequestWorkers of 1000 exceeds ServerLimit value of 256, decreasing to match

https://httpd.apache.org/docs/2.4/en/mo ... ommon.html:

The default value is 256; to increase it, you must also raise ServerLimit.

Allerdings ergibt es wenig Sinn, bei einer CPU mit 6 Kernen, die nur 12 Threads parallel abarbeiten kann, eine derart große Zahl von Threads gleichzeit abarbeiten zu wollen. Möglicherweise läuft der Server sogar effektiver, wenn du MaxRequestWorkers viel kleiner setzt, also eher etwas in der Region 20-30.

[whisper]

Wie du im Screenshot sehen kannst ist die übliche worker busy rate um die 30-60.
Da nun nur ein Limit von 20-30 einzustellen ist kontraproduktiv.
Im Vergleich zu den vhosts sieht man kein hervorstechendes Web, dass den worker Limit verursacht.
Der Server ist ist keineswegs überlastet. Nur im fall von worker am Ende des Limits ist das Antwortverhalten träge, weil da der Request eben erst beantwortet wird, wenn ein worker frei ist.

[mludwig]

wenn einzelne Requests zu lange dauern und dadurch viele gleichzeitig aktiv sind, muss der nächste halt lange warten bis wieder ein Worker frei ist. Das kann auch an einzelnen Seiten liegen, die langsame SQL-Requests absetzen - bei MySQL kann man sich z. B. lange dauernde Abfragen loggen lassen und stellt manchmal fest das irgendwo ein Index fehlt.

[whisper]

wenn einzelne Requests zu lange dauern und dadurch viele gleichzeitig aktiv sind, muss der nächste halt lange warten bis wieder ein Worker frei ist. Das kann auch an einzelnen Seiten liegen, die langsame SQL-Requests absetzen - bei MySQL kann man sich z. B. lange dauernde Abfragen loggen lassen und stellt manchmal fest das irgendwo ein Index fehlt.

Aber dann müsste man doch das auch in der vhost sparte zu sehen sein. Dummerweise gibt es keine hinweise

[whisper]

Hallo Whisper,
hast Du schon mal https://github.com/javamelody/javamelody ausprobiert?

das confluence plugin wird vom owner der site abgelehnt, wohl etwas unsicher.

Aber das System war mit dem Hund raus, hat wohl seit ein paar Wochen Probleme.
Ich habe jetzt auch Gegenmassnahmen gegen SYN_Food getroffen, obwohl das wohl laut logs nicht wirklich die Ursache ist.
Mal abwarten, wie es Morgen aussieht.

[homer65]

Schade, JavaMelody macht auf mich einen guten Eindruck. Damit kann man Performance Probleme eingrenzen. Und was genau bedeutet unsicher? Man muss es ja auch nicht ständig laufen lassen, sondern nur wenn man Probleme hat.

[heisenberg]

Wenn die Anzahl der genutzten Worker so hoch ist und die Anzahl der tatsächlich verarbeiteten Requests niedrig - wie man bei Deinen beiden Bildchen im ersten Beitrag sieht - dann ist die Durchlaufzeit der Requests auch entsprechend lang, d. h. irgendwo gibt's bei Deinem Server einen Flaschenhals (I/O, RAM, CPU oder eine Anwendung(z. B. DB) ) d. h. Überlast.

Ein paar Gedanken dazu:

• Kannst Du ein paar mehr Bildchen zeigen (netdata hat doch da einiges, am besten alles schön synchron untereinander, dass man auf der Zeitachse die Werte parallel checken kann)?
  • I/O-Aktivität (Throughput, IOPS)?
  • RAM (verbraucht, frei, swap)?
  • Anzahl Prozesse / Threads ?
  • CPU-Load ?
  • CPU-Utilization ?
• Kannst Du mal die durchschnittliche Apache-Request-Dauer mal in den Webserverlogs prüfen, ggf. mitloggen bzw. gar visualisieren?
• Was sagt denn so die DB-Auslastung? Wieviel CPU-Usage hat der DB-Prozess in Spitzenzeiten denn? ( -> top).
• Falls MySQL/MariaDB: Mal das Slow-Log einschalten und schauen, ob da viele lang laufende Abfragen sind. Vielleicht auch mal den mysqltuner laufen lassen?

Ansonsten gibt es ja für netdata afaik eine Tonne von Plugins, mit der man zusätzliche Dinge messen kann.

[whisper]

Ich habe versucht, einen Screenshot zu machen, auf der mehr Metriken sind, bin da aber gescheitert.
Na klar netdata zeigt sehr sehr viel, man kann auch sehr schön mit timeframes die Korrelation versuchen zu zeigen, doch in meinen Versuchen ist da schier gar nichts zu erkennen
Hört sich unglaublich an,deshalb mache ich noch einen Versuch mehr Metriken untereinander zu packen. Das ist überhaupt kein Problem, sondern davon dann einen Screenshot zu machen.
Habs jetzt.
Vorsicht 13MB (deshalb auch nicht im Forum, weil zu groß und zu hoch.
https://zockertown.de/netdata-workers-issue.png
Extra Brave genommen, mit fireshot.
Leider musste ich die Metriken begrenzen, alle sind zuviel für das tool.
Kann sein, das jetzt was fehlt.
Hoffe nicht

[heisenberg]

Man sieht schon, dass zum Zeitpunkt X der vielen Apache Workers, die Performance insgesamt runter geht: Weniger Postgres-Aktivität, Weniger Apache Requests, Weniger Bandbreite, die der Apache durchleitet. Aber es gibt keinen CPU-Flaschenhals.

Also: Performance geht runter -> Die Anzahl der eingehenden Anfragen/pro Sekunde bleibt vermutlich gleich, also geht gleichzeitig die Anzahl der Worker hoch, weil die Requests viel länger dauern und nicht fertig werden. Also insgesamt kommen mehr Anfragen rein, als zu dem spezifischen Zeitpunkt verarbeitet werden können.

Was mir an Grafiken fehlt, ist Storage-I/O (IOPS(lesen, schreiben) und Durchsatz(lesen, schreiben)). Zu RAM und Swap sind da auch keine Informationen zu sehen.

Ich könnnte mir vorstellen, dass da ein anderes Programm läuft, was Storage-Performance verbraucht. An RAM wird's vermutlich nicht liegen. Da ist ja massig da.

[whisper]

Was mir an Grafiken fehlt, ist Storage-I/O (IOPS(lesen, schreiben) und Durchsatz(lesen, schreiben)). Zu RAM und Swap sind da auch keine Informationen zu sehen.

Ich könnnte mir vorstellen, dass da ein anderes Programm läuft, was Storage-Performance verbraucht. An RAM wird's vermutlich nicht liegen. Da ist ja massig da.

Moin,
CPU und RAM, auch i/o ist nix, Kann aber davon auch noch metriken machen, jetzt weiß ich ja wie's geht. Alle gehen nicht, da streikt fireshot.
kann ein wenig dauern, aber das phänomen ist ja öfter, nach einem cron job sieht es nicht aus.

[whisper]

https://zockertown.de/netdata-workers-issue-2.png

[heisenberg]

Na. 170 MiB/s würde ich jetzt nicht unbedingt als Nichts bezeichnen, sondern eher als die Ursache des Problems. Ist nur noch die Frage, wer der Übeltäter ist, der das verursacht. Das sollte sich über den Graphen systemd.service.disk.io herausfinden lassen. Der Screenshot zeigt den Namen des Programmes allerdings nicht an. Da müsstest Du nochmal selber nachschauen.

Ansonsten finde ich die schiere Menge an Graphen absolut verwirrend. Da würde ich auch den Wald vor lauter Bäumen nicht mehr sehen und mir eher mal ein Dashboard mit vielleicht den 10 wichtigsten zusammenstellen, z. B.:

disk.io
disk.ops
apache.workers
apache.requests
system.cpu
cpufreq.cpufreq
ip.tcpsock
postgres.connection_connection_state_count

und noch 1-2 Graphen für RAM/Swap.

Was ich an Deinen Graphen sehr gut finde, sind die Detailgraphen, an denen man sieht welche Prozesse wieviel Systemlast jeweils verursachen. Aber die Übersicht ist echt für die Füß.

So sieht z. B. ein Teil meines Server-Dashboards aus, mit einer Graphen-Voransicht im rechten Bereich:

[schorsch_76]

Vielleicht ist das Problem ja nicht der Server sondern eine externe API die genutzt wird und dann deine Requests ausbremst....

[TRex]

heisenberg, dein Bild ist für andere nicht sichtbar (falsche Galerie).

[heisenberg]

heisenberg, dein Bild ist für andere nicht sichtbar (falsche Galerie).

Danke. fixed. (Ich hatte das Bild mehrfach gelöscht, weil ich wiederholt eine Public-IP bzw. einen Hostnamen bei der Anonymisierung übersehen hatte.)

Vielleicht ist das Problem ja nicht der Server sondern eine externe API die genutzt wird und dann deine Requests ausbremst....

Externe API ist generell ein guter Tip! Das Problem ist hier allerdings - wie dargelegt und in den Performancedaten zu sehen - dass ein Prozess ganz viel I/O verursacht und den Webserver bzw. das System ausbremst.

[whisper]

Nice!
Hier mal auf die schnelle
https://zockertown.de/netdata-workers-issue-3.png
Das hohe I/O ist das Backup

[whisper]

Problem offenbar behoben.
Gucke mir das noch eine Weile an.

Gelernt habe ich dadurch die Feinheiten von netdata.
Muss ich unbedingt mal was zu schreiben

[homer65]

Wie hast Du denn das Problem behoben? Auf das Backup kann man doch nicht verzichten.

[whisper]

Nee, das Backup ist doch nicht daran Schuld.
Behoben ist es nicht, trat nicht mehr auf ..
Aber hier kommt was neues. der Zusammenhang syn-flood und workers ...
https://zockertown.de/009-syn.png