Debian CPU Auslastung durch Apache2 sehr hoch
Hallo Zusammen,
ich habe eine VM Debian 7.11 x32 mit einem Apache2 am laufen. Jetzt stelle ich fest, dass die CPU Auslastung Dauerhaft bei 100 % liegt. Stoppe ich den Apache liegt Sie bei nahezu 0%. Jetzt bin ich natürlich am überlegen was ich geändert habe, aber ich war seit Wochen nicht verändert. Ich habe der VM 6 GB RAM gegeben und 4 CPUs vom Hypervisor.
Da ich jetzt nicht der der Typische Apache Admin bin, die Frage, wie und wo muss ich beim Debian schauen, was da los ist, damit ich die Ursache klären kann?
Der Powert die CPU so hoch bis da nichts mehr geht und Maschine einfriert: RAM und Swap läuft voll...
Danke für euren Rat!
ich habe eine VM Debian 7.11 x32 mit einem Apache2 am laufen. Jetzt stelle ich fest, dass die CPU Auslastung Dauerhaft bei 100 % liegt. Stoppe ich den Apache liegt Sie bei nahezu 0%. Jetzt bin ich natürlich am überlegen was ich geändert habe, aber ich war seit Wochen nicht verändert. Ich habe der VM 6 GB RAM gegeben und 4 CPUs vom Hypervisor.
Da ich jetzt nicht der der Typische Apache Admin bin, die Frage, wie und wo muss ich beim Debian schauen, was da los ist, damit ich die Ursache klären kann?
Der Powert die CPU so hoch bis da nichts mehr geht und Maschine einfriert: RAM und Swap läuft voll...
Danke für euren Rat!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 334303
Url: https://administrator.de/forum/debian-cpu-auslastung-durch-apache2-sehr-hoch-334303.html
Ausgedruckt am: 11.05.2025 um 06:05 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Der erste Weg ist wohl ein Blick in die Log-Files vom Apache und vom System selbst.
BFF
Der erste Weg ist wohl ein Blick in die Log-Files vom Apache und vom System selbst.
BFF
Ich bin schon einen Schritt weiter gekommen. Das Problem scheint ein Upload zu sein von einem OwnCloud Client, der wohl eine Menge Daten in meine OwnCloud schiebt. Denn sobald ich den Port 444 auf den SSL läuft schließe fällt die Last wieder auf normal. Was ich mich nur gerade Frage ist, dass darf doch garnicht sein, dass ein Client der gerade mal mit 20 KB auf eine 100 VDSL seinen Upload macht, einen Debian bzw. Apache so ins schwitzen bringt und den den Swapp bzw. CPU so hoch jagt oder?
Hat jemand einen Rat?
Hat jemand einen Rat?
Sieh nach was das fuer ein Client ist, der da Daten schiebt, und sieh nach was das fuer Daten sind.
Und weil Du grade von owncloud redest. Ist die Software aktuell?
Schau mal hier : Apache + owncloud
BFF
Und weil Du grade von owncloud redest. Ist die Software aktuell?
Schau mal hier : Apache + owncloud
BFF
Hi
Hast du eine Verschlüsselung in der OwnCloud Aktiviert?
Gruss PPR
Hast du eine Verschlüsselung in der OwnCloud Aktiviert?
Gruss PPR
Hallo,
also den Client habe ich identifiziert u. ja Owncloud Client ist aktuell u. selber nutze ich Versin 9xx Stabil.
Die Daten sind eine ziemlich heftige Ordner Struktur aus bestimmt 500 Ordner mit einigen tausend *.docs Gesamtgröße ca. 3,5 GB
Ich habe das jetzt erstmal abgeschaltet,
Nein Daten sind nicht verschlüsselt.
Habe mir gerade auch mal die Logs von Owncloud heruntergeladen.
Was mich dabei einfach irritiert ist, dass es so was doch nicht geben darf. Das ein Client eine Serveranwendung so leicht überlasten kann. Ich werde morgen früh mal ein paar Test lokal machen und mir das Ganze noch mal ansehen. Der Apache muss doch in der Lage sein sich vor so was selbst zu schützen.
Den Link oben habe ich durchgesehen, in meinen PHP.ini steht bei zlib.output_compression = off
Das kann es also auch nicht sein.
also den Client habe ich identifiziert u. ja Owncloud Client ist aktuell u. selber nutze ich Versin 9xx Stabil.
Die Daten sind eine ziemlich heftige Ordner Struktur aus bestimmt 500 Ordner mit einigen tausend *.docs Gesamtgröße ca. 3,5 GB
Ich habe das jetzt erstmal abgeschaltet,
Nein Daten sind nicht verschlüsselt.
Habe mir gerade auch mal die Logs von Owncloud heruntergeladen.
Was mich dabei einfach irritiert ist, dass es so was doch nicht geben darf. Das ein Client eine Serveranwendung so leicht überlasten kann. Ich werde morgen früh mal ein paar Test lokal machen und mir das Ganze noch mal ansehen. Der Apache muss doch in der Lage sein sich vor so was selbst zu schützen.
Den Link oben habe ich durchgesehen, in meinen PHP.ini steht bei zlib.output_compression = off
Das kann es also auch nicht sein.
Hallo,
Da werden irgendwelche Limitierungen greifen oder nicht greifen.
Hast Du die Moeglichkeit auf einen Debian x64 umzustellen? Und welche Version Apache und PHP hast Du?
BFF
Da werden irgendwelche Limitierungen greifen oder nicht greifen.
Hast Du die Moeglichkeit auf einen Debian x64 umzustellen? Und welche Version Apache und PHP hast Du?
BFF
Moin,
Womit du dein Problem an sich recht gut beschrieben hast. OwnCloud so wie NextCloud sind nicht dafür gemacht viele kleine Dateien zu synchronisieren. Wenn jetzt noch eine unschöne apache version bzw. forking/threading hinzukommt, eine ungünstige PHP version, vielleicht noch die Abwesenheit von memcache oder redis, schaukelt sich das alles schnell hoch.
Ich würde erstmal schauen, welche Worker-Strategie dein Apache fährt. Dann würde ich erstmal einen memcache oder redis dranflanschen, was deine Datenbank entlastet. Wenn dein Problem daraufhin weiterhin besteht würde ich weiter analysieren. Aber aktuell klingt das nach vielen einzelnen HTTP-Calls, die eine recht mächtige PHP Anwendung aufrufen, was Apache so überhaupt nicht mag.
Gruß
Chris
Die Daten sind eine ziemlich heftige Ordner Struktur aus bestimmt 500 Ordner mit einigen tausend *.docs Gesamtgröße ca. 3,5 GB
Womit du dein Problem an sich recht gut beschrieben hast. OwnCloud so wie NextCloud sind nicht dafür gemacht viele kleine Dateien zu synchronisieren. Wenn jetzt noch eine unschöne apache version bzw. forking/threading hinzukommt, eine ungünstige PHP version, vielleicht noch die Abwesenheit von memcache oder redis, schaukelt sich das alles schnell hoch.
Ich würde erstmal schauen, welche Worker-Strategie dein Apache fährt. Dann würde ich erstmal einen memcache oder redis dranflanschen, was deine Datenbank entlastet. Wenn dein Problem daraufhin weiterhin besteht würde ich weiter analysieren. Aber aktuell klingt das nach vielen einzelnen HTTP-Calls, die eine recht mächtige PHP Anwendung aufrufen, was Apache so überhaupt nicht mag.
Gruß
Chris
Hallo Zusammen,
danke für die vielen Infos. Ja es ist so wie so geplant auf Debian 8 x64 umzustellen und dann den Apache und OwnCloud umziehen zu lassen! PHP ist bei mir 5.5.38 Apache Version 2.22
Ich habe den Übeltäter gerade identifiziert! Es ist die Antivirus App for files 0.8.1.0 in OwnCloud.
Habe gerade einen Testdatenbestand aus 45 Ordnern mit 45 Dateien von Typ: AVI, DOC, EXE, JPG, MDB, PDF, RAR und XLS hochgeladen mit einer Gesamtgröße von 1 GB. Dabei habe ich die App immer aktiviert und deaktiviert und sobald die App aktiv ist beim Upload gehts rauf auf 100% bei der CPU und der RAM läuft voll. Bei deaktivierter App, alles normal Last bei 20% und der RAM pendelt sich ein.
Die App steht mit der Standardeinstellung:
Jetzt steht die Einstellung auf Deamon mit 1024 Byte und sofort fällt die Last...
danke für die vielen Infos. Ja es ist so wie so geplant auf Debian 8 x64 umzustellen und dann den Apache und OwnCloud umziehen zu lassen! PHP ist bei mir 5.5.38 Apache Version 2.22
Ich habe den Übeltäter gerade identifiziert! Es ist die Antivirus App for files 0.8.1.0 in OwnCloud.
Habe gerade einen Testdatenbestand aus 45 Ordnern mit 45 Dateien von Typ: AVI, DOC, EXE, JPG, MDB, PDF, RAR und XLS hochgeladen mit einer Gesamtgröße von 1 GB. Dabei habe ich die App immer aktiviert und deaktiviert und sobald die App aktiv ist beim Upload gehts rauf auf 100% bei der CPU und der RAM läuft voll. Bei deaktivierter App, alles normal Last bei 20% und der RAM pendelt sich ein.
Die App steht mit der Standardeinstellung:
Jetzt steht die Einstellung auf Deamon mit 1024 Byte und sofort fällt die Last...
Moin,
Stimmt, die gibt es ja auch noch. Du solltest clamAV als Service laufen lassen und es über http pipen, sonst wirkt das ein bisschen wie eine Forkbomb. Das war zumindest meine Erfahrung.
Inzwischen habe ich es aber mit dem Umzug auf Nextcloud komplett abgestellt. Hat mitunter den Hintergrund, dass wir keine Windows Clients mehr haben.
Es freut mich jedenfalls, dass du es gefunden hast.
Gruß
Chris
Stimmt, die gibt es ja auch noch. Du solltest clamAV als Service laufen lassen und es über http pipen, sonst wirkt das ein bisschen wie eine Forkbomb. Das war zumindest meine Erfahrung.
Inzwischen habe ich es aber mit dem Umzug auf Nextcloud komplett abgestellt. Hat mitunter den Hintergrund, dass wir keine Windows Clients mehr haben.
Es freut mich jedenfalls, dass du es gefunden hast.
Gruß
Chris
Danke 
Was meinst du mit http pimpen hast du eine Anleitung für?
Was meinst du mit http pimpen hast du eine Anleitung für?
Moin,
Oh ein Fehler meinerseits: Über TCP pipen natürlich.
Und zur Anleitung bitte hier entlang: https://doc.owncloud.org/server/latest/admin_manual/configuration_server ...
Bzw. für Version 8 (sollte nicht anders sein): https://doc.owncloud.org/server/8.1/admin_manual/configuration_server/an ...
Gruß
Chris
Oh ein Fehler meinerseits: Über TCP pipen natürlich.
Und zur Anleitung bitte hier entlang: https://doc.owncloud.org/server/latest/admin_manual/configuration_server ...
Bzw. für Version 8 (sollte nicht anders sein): https://doc.owncloud.org/server/8.1/admin_manual/configuration_server/an ...
Gruß
Chris
danke
