Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] php laufzeit und ressourcenverbrauch überwachen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] php laufzeit und ressourcenverbrauch überwachen

    Hallo Leute

    ich würd gerne auf meinem Debian-System die Laufzeit und den Ressourcenverbrauch von _allen_ PHP Scripten überwachen. Will damit feststellen, welches Script eventuell zu viele ressourcen verbrät und den apache in die knie zwingt. Ist es möglich den Ressourcen-Verbrauch einem Script / Ordner zuzuordnen?

    Ich bedanke mich schonmal für jeden Hilfe-Versuch

  • #2
    Re: php laufzeit und ressourcenverbrauch überwachen

    Zitat von fonsorello
    ich würd gerne auf meinem Debian-System die Laufzeit und den Ressourcenverbrauch von _allen_ PHP Scripten überwachen.
    Ein "paranoider" Ansatz.
    Will damit feststellen, welches Script eventuell zu viele ressourcen verbrät und den apache in die knie zwingt.
    Wie stellst Du Dir das mit PHP vor, wenn der Apache gerade auf dem letzten Loch pfeift?
    Ist es möglich den Ressourcen-Verbrauch einem Script / Ordner zuzuordnen?
    Ja klar. In einer lokalen php.ini (CGI) oder mit einer directory Direktive (mod_php) kannst Du zumindest für einen "Verzeichnis-Ast" memory_limit ändern.

    Das generelle Problem bei Überwachungsscripts ist, daß sie genau dann, wenn es brenzlig wird, für den "Gnadenschuß" sorgen.

    Meist ist es allerdings nicht der Apache sondern der MySQL Server, der bei zuwenig RAM aus einem flotten Rechner eine lahme Krücke macht. Abhilfe: mehr RAM u/o pconnect verbieten.

    Kommentar


    • #3
      @meikel

      Abhilfe: mehr RAM u/o pconnect verbieten
      Mehr Speicher ist klar - unklar ist mir pconnect

      Mein Stand ist das es hierbei doch um den connect zur DB geht, innerhalb des ablaufenden Scripts. D.h. Script fertisch -> connect weg !!

      Der Speicher wird nach auslesen ge-flushed (pro abfrage) sofern
      mysql_free_result() gibt den Speicher frei, der mit der Ergebnis-Kennung assoziert ist.

      Was ist an pconnect schlecht ??

      Kommentar


      • #4
        Zitat von ulle
        Abhilfe: mehr RAM u/o pconnect verbieten
        Mehr Speicher ist klar - unklar ist mir pconnect
        Koehntopp hatte im usenet (de.comp.lang.php.*, ca. 1-2 Jahre her) mal recht anschaulich beschrieben, wie man mit exzessiven pconnect einen Server töten kann. Leider finde ich den Text nicht mehr, hoffe aber, daß Du mir das eventuell auch ohne Zitat glauben könntest.

        Kommentar


        • #5
          Ich glaube Dir das gerne :wink:

          Nur verstehen würde ich noch lieber,

          ich werde mich mal auf die Suche machen schliesslich benutze ich pconnect

          evtl. Gibt es ja mit einer 4.3.x dieses Thema ja gar nicht mehr

          Kommentar


          • #6
            gefunden

            Zitat von Kristian Köhntopp
            16.8. Was ist der Unterschied zwischen connect und pconnect?

            Antwort von Kristian Köhntopp
            In PHP bieten die meisten Datenbanken zwei connect()-Funktionen an: Eine gewöhnliche und eine pconnect()-Funktion. Verwendet man CGI PHP, unterscheiden sich beide Funktionen nicht.

            Verwendet man das PHP-Modul, werden die mit einem connect() hergestellten Datenbankverbindungen am Ende der Seite geschlossen. Mit pconnect() hergestellte Verbindungen bleiben jedoch geöffnet. Dies dient einzig und alleine dazu, das ständige Öffnen und Schließen von Netzwerkverbindungen zu vermeiden, denn der Verbindungsaufbau ist bei einigen Datenbanken (etwa Oracle) sehr aufwendig.

            Es ist daher empfehlenswert, in jedem Fall die pconnect()-Variante zu verwenden (aber: Vergleiche http://kris.koehntopp.de/artikel/webtune/. Es können sehr viele offene Datenbankverbindungen entstehen). Siehe auch: PHP Manual, http://de3.php.net/manual/de/feature...onnections.php.
            :
            In CGI PHP wird auf einer Webseite irgendwann einmal ein mysql_connect() oder mysql_pconnect() ausgeführt. PHP stellt in diesem Moment eine Verbindung zu Datenbank her und arbeitet dann mit dieser Verbindung. Spätestens am Ende der Seite endet das PHP-Programm und mit ihm auch der PHP-Interpreterprozeß selbst. Dadurch werden alle Filehandles dieses Prozesses geschlossen, also auch die Datenbankverbindung. CGI PHP wird also in schneller Folge Datenbankverbindungen öffnen und schließen, und es wird maximal so viele Datenbankverbindungen geben, wie es parallele PHP-Interpreter geben kann, nämlich "MaxClients" viele. Man muß den Datenbankserver vom RAM und vom Serverprozeß her so konfigurieren, daß er mit einer solchen Anzahl von parallelen Sessions fertig werden kann!
            :
            Wenn in mod_php mit mysql_connect() gearbeitet wird, verhält es sich exakt so wie CGI PHP: Am Ende der Webseite wird die Datenbankverbindung geschlossen. Anders bei mysql_pconnect(): Da der Interpreter als Modul Bestandteil des Bearbeiterprozesses des Webservers ist, kann dieser die Verbindung auch nach dem Ende der Webseite offen halten. Fordert später eine andere Webseite eine Verbindung mit denselben Host/User/Paßwort-Daten an, kann der Bearbeiterprozeß diese existierende Verbindung anbieten, anstatt erneut eine solche Verbindung eröffnen zu müssen. Bei mysql_pconnect() hat dies wegen der Geschwindigkeit von MySQL nur vergleichsweise geringe Auswirkungen; verwendet man hingegen Oracle, sind mod_php und ora_plogon() absolut essentiell, wenn man Performance braucht.
            :
            Der unterschied liegt im CGI PHP / Modul-Version, demnach ist meine Ausage von oben nur bedingt richtig nur bei CGI PHP

            Bei mysql_pconnect() hat dies wegen der Geschwindigkeit von MySQL nur vergleichsweise geringe Auswirkungen;

            ergo keine pconnect keine Probleme

            Kommentar


            • #7
              Zitat von ulle
              Nur verstehen würde ich noch lieber,
              Das Problem war, wenn ich mich nicht irre, folgendes:
              bei pconnect wird die Verbindung ja nicht getrennt. Dh. der Prozeß mit dem dazugehörigen mysql client verbleibt weiterhin im Arbeitsspeicher. Er wird nur beim nächsten Kontakt des gleichen Scriptes aber anderer Apacheprozeß nicht "wiedergefunden" [1]. So wird auf stark frequentierten Webservern der RAM mit "pconnect Leichen" vollgemüllt. Und wenn der MySQL Server wegen Speichermangel zu swappen beginnt, geht der Server schlagartig in die Knie.

              Bei einem "normalen" *_connect wird die Verbindung bei Scriptende getrennt und der "Verbindungsprozeß" gekillt.

              [1] Ob das Problem mittlerweile gelöst wurde (andere Apache-, PHP- u/o MySQL Client Version) , weiß ich nicht.

              Kommentar


              • #8
                sorry - habe in Deine Antwort editiert


                Danke Dir

                Kommentar


                • #9
                  Koehntopps Text:

                  Den Text kenne ich auch. Allerdings meinte ich einen anderen Text. In dem hatte er vorgerechnet, wie der Speicherverbrauch in die Knie geht, weil auch bei mod_php Speicher verbraten wird. "Unter dem Strich" kam jedenfalls raus, daß auf einem hochfrequentierten Server auch bei mod_php *_pconnect mehr schadet als nutzt, wenn nicht genug RAM vorhanden ist.

                  ##EDIT:

                  einfach mal mit top testen, wieviele Apache- und MySQL Prozesse im Speicher rumhängen und wieviel RAM sie belegen.

                  Kommentar


                  • #10
                    Re: php laufzeit und ressourcenverbrauch überwachen

                    Zitat von meikel
                    Ein "paranoider" Ansatz.

                    Das generelle Problem bei Überwachungsscripts ist, daß sie genau dann, wenn es brenzlig wird, für den "Gnadenschuß" sorgen.
                    Hi, erstmal vielen Dank für die Antworten.

                    Ich hatte das wohl nicht so gut formuliert .. ich habe keineswegs die Absicht die laufzeit und den ressourcen-verbrauch der scripte mit einem zusätzlichen script zu messen. Das macht keinen Sinn, da gebe ich Dir recht. Wenn ich das machen wollte, würd ich in der php.ini die pre- und append files angeben, mit entsprechendem code füllen und das wärs. Und vor dieser Lösung graust mir etwas.

                    Ich wollte die Infos eher wo her holen, wo sie sowieso schon vorliegen, z.B. beim Apache. Ich weis nur nicht ob das überhaupt geht, oder ob es vill Tools gibt die genau das machen.

                    so long

                    Kommentar


                    • #11
                      Ich denke mal du suchst sowas wie den Performance Monitor unter Windows, wo man gezielt sogar Laufzeitinformationen aus dem ASP-Interpreter bekommen kann.

                      Für PHP kenne ich sowas leider auch nicht. Ich bezweifle sogar, das PHP sowas überhaupt kann.

                      Bin aber gerne bereit mich vom Gegenteil überzeugen zu lassen.

                      Kommentar


                      • #12
                        Re: php laufzeit und ressourcenverbrauch überwachen

                        Zitat von fonsorello
                        Ich wollte die Infos eher wo her holen, wo sie sowieso schon vorliegen, z.B. beim Apache. Ich weis nur nicht ob das überhaupt geht, oder ob es vill Tools gibt die genau das machen.
                        Ich starte via cron folgendes CLI Script:
                        Code:
                        #!/usr/bin/php -q 
                        <?php
                        require (dirname(__file__).'/config.php');
                        $name = time();
                        
                        shell_exec("/usr/bin/pstree > "$datapath/pstree.txt");
                        shell_exec("/bin/chmod 0644 $datapath/pstree.txt");
                        shell_exec("/bin/chown $uid:$gid $datapath/pstree$name.txt");
                        
                        shell_exec("/usr/bin/top -b -n 1 > $datapath/top.txt");
                        shell_exec("/bin/chmod 0644 $datapath/top.txt");
                        shell_exec("/bin/chown $uid:$gid $datapath/top$name.txt");
                        ?>
                        Bei Bedarf gucke ich dann mir die Textfiles an. Was älter als eine Woche ist, wird dann in die Tonne getreten.

                        Kommentar


                        • #13
                          @ meikel

                          Ich kenne mich mit Linux zwar noch nicht soo gut aus, aber dein Script wundert mich etwas: Warum führst du die Befehle, die du über den PHP-Interpreter an die Shell weitergibst (shell_exec) nicht direkt in der Shell aus (wie ein normales Shellscript)? Ist das nicht etwas umständlich?

                          KMAssS

                          Kommentar


                          • #14
                            Zitat von kmasss
                            ... aber dein Script wundert mich etwas: Warum führst du die Befehle, die du über den PHP-Interpreter an die Shell weitergibst (shell_exec) nicht direkt in der Shell aus (wie ein normales Shellscript)? Ist das nicht etwas umständlich?
                            Das Script ist nur ein Auszug aus einem größeren Script, welches via cron gestartet wird.

                            Kommentar


                            • #15
                              Mit APD durch die PHP Scripte gehen

                              Ich habe mich vor einer Weile mit einer ähnlichen Frage konfrontiert und bin auf folgenden Artikel im Linux Journal gestossen:

                              http://www.linuxjournal.com/print.php?sid=7213 - PHP Performance Profiling

                              Wie man sich die CPU Auslastung 'aller' PHP Scripte welche auf einem Server laufen anschaut, weiss ich nicht. Bei APD musst Du im aufgerufenen Script eine Funktion zu Beginn ausführen.
                              Mit APD kannst Du auf jeden Fall deine Applikationen nach Bottlenecks durchsuchen und bei mir hat es sich wirklich ausgezahlt. Es ist auch weniger interessant welche Zeit ein Script tatsächlich benötigt, sondern mehr das Verhältnis zu den anderen Scripten, somit ist es zimlich egal wie fest dein Server bereits ausgelastet ist.

                              Kommentar

                              Lädt...
                              X