7
Httpd sorgt für 100 Prozent CPU Last
Hallo allerseits,
es besteht ein größeres Problem mit unsrem Apache:
- Windows Server 2012 R2
- Apache 2.4
- MoinMoinWiki (aktuelle Version) mit ldap Anbindung zum AD
- virtuelle Maschine
Absolut nicht nachstellbar und scheinbar völlig zufällig (mal nachts, mal abends, mal mittags) lastet der httpd Prozess die CPU auf 100% aus, somit funktioniert das Wiki nicht mehr und der Server wird unbedienbar. Lediglich https Prozess abschießen und Apache neustarten löst das Problem.
Es lässt sich schlicht nicht reproduzieren, egal was man macht man bekommt nicht raus wann und wo das Problem besteht.
Ausgeschlossen habe ich bereits den Apache (Parameter nach Recherchen hochgesetzt oder runter, Konfigurationen optimiert etc. Ldap-Cache ausgeschlossen etc.), mögliche Virenscannungen, Updates oder ähnliches.
Ich vermute es ist das MoinMoinWiki, leider ist das so undurchsichtig aufgebaut (und von Python habe ich keine Ahnung), dass ich keine guten Ansätze finde.
Hat jemand noch ein paar Ideen woran es liegen könnte? Eventviewer sagt nichts, Procmon hat auch nicht geholfen bei der Analyse.
Ich bin ziemlich ratlos.
Citronella
es besteht ein größeres Problem mit unsrem Apache:
- Windows Server 2012 R2
- Apache 2.4
- MoinMoinWiki (aktuelle Version) mit ldap Anbindung zum AD
- virtuelle Maschine
Absolut nicht nachstellbar und scheinbar völlig zufällig (mal nachts, mal abends, mal mittags) lastet der httpd Prozess die CPU auf 100% aus, somit funktioniert das Wiki nicht mehr und der Server wird unbedienbar. Lediglich https Prozess abschießen und Apache neustarten löst das Problem.
Es lässt sich schlicht nicht reproduzieren, egal was man macht man bekommt nicht raus wann und wo das Problem besteht.
Ausgeschlossen habe ich bereits den Apache (Parameter nach Recherchen hochgesetzt oder runter, Konfigurationen optimiert etc. Ldap-Cache ausgeschlossen etc.), mögliche Virenscannungen, Updates oder ähnliches.
Ich vermute es ist das MoinMoinWiki, leider ist das so undurchsichtig aufgebaut (und von Python habe ich keine Ahnung), dass ich keine guten Ansätze finde.
Hat jemand noch ein paar Ideen woran es liegen könnte? Eventviewer sagt nichts, Procmon hat auch nicht geholfen bei der Analyse.
Ich bin ziemlich ratlos.
Citronella
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 295617
Url: https://administrator.de/contentid/295617
Printed on: April 23, 2024 at 07:04 o'clock
7 Comments
Latest comment
Was sagt denn das Apache-Log selbst?
Seit wann besteht das Problem (präziser: Zu dem Zeitpunkt, als das Problem das erste Mal auftauchte, was hat sich am Server geändert?)?
Seit wann besteht das Problem (präziser: Zu dem Zeitpunkt, als das Problem das erste Mal auftauchte, was hat sich am Server geändert?)?
Moin,
klingt so als würde sich irgend ein Script "aufhängen" oder in einer Endlosschleife befinden. Steht was im Log?
Gibt es ein Supportforum für das MoinMoinWiki wo du nachfragen kannst? Ansonsten einfach mal in den IIS migrieren?
Ich würde aber auf einem produktiven System keinen Apache unter Windows verwenden wenn es nicht unbedingt sein muss, denn Microsoft hat doch extra seinen IIS dafür.
Einen Apache würde ich immer dort belassen wo er hin gehört, auf ein Linux!
VG
Val
klingt so als würde sich irgend ein Script "aufhängen" oder in einer Endlosschleife befinden. Steht was im Log?
Gibt es ein Supportforum für das MoinMoinWiki wo du nachfragen kannst? Ansonsten einfach mal in den IIS migrieren?
Ich würde aber auf einem produktiven System keinen Apache unter Windows verwenden wenn es nicht unbedingt sein muss, denn Microsoft hat doch extra seinen IIS dafür.
Einen Apache würde ich immer dort belassen wo er hin gehört, auf ein Linux!
VG
Val
Moin,
hat denn die VM genau Ghz / Cores / RAM / IO zugewiesen? Evtl. kommt die "Last" auch vom Hostsystem... wie siehts denn auf dem Hypervisor aus?
lg,
Slainte
hat denn die VM genau Ghz / Cores / RAM / IO zugewiesen? Evtl. kommt die "Last" auch vom Hostsystem... wie siehts denn auf dem Hypervisor aus?
lg,
Slainte
Hallo,
ich kenn mich jetzt zwar mit Python nicht aus, aber wenn es sich halbwegs wie PHP verhält dann wäre die Frage, ob es als Modul oder CGI läuft. Hängende PHP-Scripte reißen beim Windows-Apachen mit in die Tiefe, wenn PHP als Modul läuft und nicht threadsafe konfiguriert ist (leider beim Windows-Inidianer der Standardfall). Braucht Python unter Windows nicht auch noch Cygwin? Das wären dann aber verdammt viele Variablen...
Ich würde jedenfalls auch auf ein hängendes Script tippen. Der Rat von Valexus ist jedenfalls nicht verkehrt: Apache unter Windows ist nur was für Testumgebungen, nicht für den Produktiveinsatz.
Grüße
Cody
ich kenn mich jetzt zwar mit Python nicht aus, aber wenn es sich halbwegs wie PHP verhält dann wäre die Frage, ob es als Modul oder CGI läuft. Hängende PHP-Scripte reißen beim Windows-Apachen mit in die Tiefe, wenn PHP als Modul läuft und nicht threadsafe konfiguriert ist (leider beim Windows-Inidianer der Standardfall). Braucht Python unter Windows nicht auch noch Cygwin? Das wären dann aber verdammt viele Variablen...
Ich würde jedenfalls auch auf ein hängendes Script tippen. Der Rat von Valexus ist jedenfalls nicht verkehrt: Apache unter Windows ist nur was für Testumgebungen, nicht für den Produktiveinsatz.
Grüße
Cody
Hallo allerseits,
vielen Dank für die Anregungen und Ideen.
Grundlegend habt ihr recht, dass es keine gute Entscheidung war auf Apache unter Windows das wiki laufen zu lassen. Ganz klar ist mir das eh nicht, zuvor hatten wir MoinMoinWiki auf IIS, nach dem Update wurde dies aber auf Apache umgezogen aus welchen Gründen auch immer und jetzt steh ich da mit der Problematik.
Ich habe einige Optimierungswerte in der Apacheconfig gesetzt, ein paar Ideen ausprobiert und seitdem war zumindest erstmal nix mehr. Das heißt aber noch gar nichts, denn zuvor lief alles auch bis zu 2 Wochen ohne Probleme.
Ich lasse nun testen, ob es problemlos ist das MoinMoinWiki auf IIS umzuziehen und ggf. sind dann die Probleme gänzlich weg.
Das Thema FastCGI war auch ein Ansatzpunkt, da sind wird aber mangels Website und Doku gescheitert (und da fehlt mir auch der Zusammenhang konkret).
Das Hostsystem ist nicht das Problem unser Hyper-V Cluster langweilt sich zu Tode.
Geändert wurde übrigens eines: Altes MoinMoinWiki wurde aktualisiert und Schritt für Schritt auf den neuen Server und Apache umgezogen.
Ich denke das Problem hat sich gelöst durch Umzug auf IIS demnächst. Falls nicht melde ich mich nochmal (als info für andere leidende).
Danke!
vielen Dank für die Anregungen und Ideen.
Grundlegend habt ihr recht, dass es keine gute Entscheidung war auf Apache unter Windows das wiki laufen zu lassen. Ganz klar ist mir das eh nicht, zuvor hatten wir MoinMoinWiki auf IIS, nach dem Update wurde dies aber auf Apache umgezogen aus welchen Gründen auch immer und jetzt steh ich da mit der Problematik.
Ich habe einige Optimierungswerte in der Apacheconfig gesetzt, ein paar Ideen ausprobiert und seitdem war zumindest erstmal nix mehr. Das heißt aber noch gar nichts, denn zuvor lief alles auch bis zu 2 Wochen ohne Probleme.
Ich lasse nun testen, ob es problemlos ist das MoinMoinWiki auf IIS umzuziehen und ggf. sind dann die Probleme gänzlich weg.
Das Thema FastCGI war auch ein Ansatzpunkt, da sind wird aber mangels Website und Doku gescheitert (und da fehlt mir auch der Zusammenhang konkret).
Das Hostsystem ist nicht das Problem unser Hyper-V Cluster langweilt sich zu Tode.
Geändert wurde übrigens eines: Altes MoinMoinWiki wurde aktualisiert und Schritt für Schritt auf den neuen Server und Apache umgezogen.
Ich denke das Problem hat sich gelöst durch Umzug auf IIS demnächst. Falls nicht melde ich mich nochmal (als info für andere leidende).
Danke!
Also nochmal ein Update:
Wir haben nicht auf den IIS umgezogen aus verschiedenen Gründen (irrelevant für das Problem).
Ich habe einige Einstellungen was die child-Prozesse angeht. Es lag nicht am LDAP Cache, sondern an den Prozessen.
Einerseits war es die EInstellung max Child Threads auf 250 hochgesetzt und noch einiges anderes, leider ist das so lange her, ich kann es nicht mehr rausfinden was ich alles konfiguriert habe.
Aufjedenfall ist seitdem absolute Ruhe und das Problem gelöst.
Wir haben nicht auf den IIS umgezogen aus verschiedenen Gründen (irrelevant für das Problem).
Ich habe einige Einstellungen was die child-Prozesse angeht. Es lag nicht am LDAP Cache, sondern an den Prozessen.
Einerseits war es die EInstellung max Child Threads auf 250 hochgesetzt und noch einiges anderes, leider ist das so lange her, ich kann es nicht mehr rausfinden was ich alles konfiguriert habe.
Aufjedenfall ist seitdem absolute Ruhe und das Problem gelöst.
Danke für die Rückmeldung. Bei MaxChildThreads muss man langsam zu Werke gehen. Zwar kann der Wert eigentlich nicht zu hoch eingestellt werden, denn wenn die CPU von der Performance nicht mehr nach kommt wird sie den eingestellten Wert nicht erreichen. Ein zu kleiner Wert kann dazu führen, dass Browseranfragen schlicht verworfen werden oder im Nirvana landen. Man sollte aber bedenken, dass ein hoher Wert z.B. bei DDoS-Attacken dazu führen kann dass sich die CPU tot rennt und keine Reserven für die übrigen Systemprozesse übrig bleiben. Da spielt aber vieles mit rein (u.A. Prozess- und Speichermanagement vom Kernel)
