2
Gibt es eine übergreifene Möglichkeit für ein PHP-Logging?
Hallo,
ein Kunde von uns hat ein merkwürdiges Problem mit seinem eShop Magento.
Das ganze läuft auf einer physikalischen Maschiene mit CentOS 6.2 64Bit.
Dual CPU, 200 GB RAM, SAS Festplatten, MySQL auf einem seperaten PC.
Problem ist, dass der Server unregelmäßig eine sehr hohe CPU Last erzeugt und nicht mehr erreichbar ist.
Nicht mehr erreichbar betrifft alle Dienste inklusive Munin und SSH.
Lokal an der Maschiene kann man dann apache neu starten und alles geht wieder.
RAM ist genug frei, kein swapping.
Unregelmäßig heißt, mal läufts 3 Tage, dann tritt es täglich auf, meinst aber alle 2-3 Tage.
So weit man das in Munin noch sehen kann auch sehr nahe einer vollen Stunden.
Deshalb dachte ich an CronJobs, aber zu diesem Zeitpunkt liefen keine.
Größere externe Zugriff auf den Apache gab es zu diesem Zeitpunkt auch keine.
Auch müßte der Server ja nach einiger Zeit fertig sein.
Aber auch nach 12 Stunden hat sich nichts gebessert.
Wir haben uns das System mit XDebug angeschaut, aber XDebug kann ich aufgrund der Datenmenge nicht tagelang laufen lassen.
Kennt Jemand ein lightweight php profiling oder ein übergerifenedes php logging?
Da ich die Quelle nicht kenne, kann ich nicht in Magento einfügen. Also müßte es direkt in PHP laufen.
Folgende Daten wäre interessant: Aufruf (URL), Parameter, Startzeit, Endzeit, (Dauer), Speichernutzung, CPU-Nutzung
Vielen Dank
Stefan
ein Kunde von uns hat ein merkwürdiges Problem mit seinem eShop Magento.
Das ganze läuft auf einer physikalischen Maschiene mit CentOS 6.2 64Bit.
Dual CPU, 200 GB RAM, SAS Festplatten, MySQL auf einem seperaten PC.
Problem ist, dass der Server unregelmäßig eine sehr hohe CPU Last erzeugt und nicht mehr erreichbar ist.
Nicht mehr erreichbar betrifft alle Dienste inklusive Munin und SSH.
Lokal an der Maschiene kann man dann apache neu starten und alles geht wieder.
RAM ist genug frei, kein swapping.
Unregelmäßig heißt, mal läufts 3 Tage, dann tritt es täglich auf, meinst aber alle 2-3 Tage.
So weit man das in Munin noch sehen kann auch sehr nahe einer vollen Stunden.
Deshalb dachte ich an CronJobs, aber zu diesem Zeitpunkt liefen keine.
Größere externe Zugriff auf den Apache gab es zu diesem Zeitpunkt auch keine.
Auch müßte der Server ja nach einiger Zeit fertig sein.
Aber auch nach 12 Stunden hat sich nichts gebessert.
Wir haben uns das System mit XDebug angeschaut, aber XDebug kann ich aufgrund der Datenmenge nicht tagelang laufen lassen.
Kennt Jemand ein lightweight php profiling oder ein übergerifenedes php logging?
Da ich die Quelle nicht kenne, kann ich nicht in Magento einfügen. Also müßte es direkt in PHP laufen.
Folgende Daten wäre interessant: Aufruf (URL), Parameter, Startzeit, Endzeit, (Dauer), Speichernutzung, CPU-Nutzung
Vielen Dank
Stefan
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: 205933
Url: https://administrator.de/forum/gibt-es-eine-uebergreifene-moeglichkeit-fuer-ein-php-logging-205933.html
Ausgedruckt am: 05.04.2025 um 14:04 Uhr
2 Kommentare
Neuester Kommentar
Kennt Jemand ein lightweight php profiling oder ein übergerifenedes php logging?
syslog() evtl. ? - http://php.net/manual/de/function.syslog.phpFolgende Daten wäre interessant: ... CPU-Nutzung
sys_getloadavg() - http://php.net/manual/en/function.sys-getloadavg.php
Hallo nxclass,
ja, fast.
Ich hätte aber gerne etwas eine Nummer tiefer.
Also nicht im PHP-Skript sondern im PHP-Programm. Z.B. ein Modul.
Magento und seine extensions bestehen aus "sehr vielen" php-dateien.
Ich kann es ohne Probleme in die Hauptdatei einfügen.
Aber wenn z.B. ein Cron eine Sub-Sub-Datei aufruft bekomme ich das dann ja nicht mit.
Stefan
ja, fast.
Ich hätte aber gerne etwas eine Nummer tiefer.
Also nicht im PHP-Skript sondern im PHP-Programm. Z.B. ein Modul.
Magento und seine extensions bestehen aus "sehr vielen" php-dateien.
Ich kann es ohne Probleme in die Hauptdatei einfügen.
Aber wenn z.B. ein Cron eine Sub-Sub-Datei aufruft bekomme ich das dann ja nicht mit.
Stefan
