Ankündigung

Einklappen
Keine Ankündigung bisher.

Prozessorauslastung fällt während Skript läuft (unter Ubuntu)

Einklappen

Neue Werbung 2019

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

  • Prozessorauslastung fällt während Skript läuft (unter Ubuntu)

    UPDATE: Problem erkannt, hat nichts mit php zu tun, hängt mit dem precaching von dateisystemen unter ubuntu zusammen (offenbar). vgl letzten post. kann mir damit jemand helfen?


    Hallo allerseits!
    ich hoffe mal im voraus, dass ich mit meinem ersten post hier im forum nicht alles falsch mache, konnte allerdings suchenderweise keine lösungen für das angetroffene problem finden. ich weiß zudem nicht, obs ein problem von php ist, oder mit ubuntu zusammenhängt, aber ich bin mittlerweile völlig ratlos.

    kurz zusammengefasst: bei bestimmten skripts mit langen laufzeiten fällt nach kurzer zeit die prozessorauslastung auf ein bruchteil (vorher 100% auslastung, nachher vielleicht 20-40%) und die skriptlaufzeit steigt entsprechend brachial an.
    das seltsamste an dem ganzen ist, dass das problem
    a) nicht genau reproduzierbar ist (die verlangsamung setzt nicht immer zur selben zeit ein) und
    b) nach einigen durchläufen des skripts nicht mehr auftritt. dann arbeiten alle belegten threads auf 100%, bis das skript terminiert. starte ich dann allerdings ein anderes, ähnliches skript, tritt das problem wieder auf, und ist wiederum erst nach einigen durchläufen verschwunden. das ist zwar eine lösung, aber nicht wirklich befriedigend, v.a. wenn das skript verlangsamt etwa 15-45 minuten laufzeit hat. ich habe auch noch kein zuverlässiges muster erkennen können.

    die skripten, bei denen dies auftritt, arbeiten ein verzeichnis mit zw. 70k und 350k html-dateien ab, formatieren und filtern diese (per regulären ausdrücken) und erzeugen postgresql-dumps zum einbinden der daten in datenbanken.
    mir ist bewusst, dass man für solche aufgaben eher andere sprachen verwenden würde, aber php bietet einige funktionalitäten, die ich bspw. unter perl vermissen würde.

    mein arbeitsrechner ist ein xeon 3550 mit 24gb ram, ich benutze ubuntu 10.10 mit gnome als oberfläche sowie php 5.3.2.

    das problem ist besonders auffällig, wenn ich die skripten multithreaded laufen lasse: hierbei verwende ich einen wrapper für pcntl_fork() (vgl.HIER).
    das skript erzeugt damit für die ersten 5-10 sekunden vollast auf allen 8 threads (oder sovielen wie gewünscht), dann fällt die leistung ab, 7 threads laufen idle und einer hat fortan wie im vorherigen fall 20-40% last.
    das bedeutet also, dass ubuntu scheinbar alle entstandenen prozesse auf einen einzigen, gedrosselten thread zusammenlegt.
    tritt das problem nicht auf, läuft so ein skript nur zw. 1 und 6 minuten, sonst kann es schon mal 45 minuten laufen.

    das problem tritt auch auf, wenn ich per nice die priorität der prozesse festlege oder die affinität der prozesse vorgebe. genauso hat es nichts geholfen, sämtliche energiesparmaßnahmen zu deaktivieren (wobei das ja eh keinen sinn machen würde, dei cores sind ja nicht mehr ausgelastet wenn es passiert)

    falls ich wichtige informationen vergessen haben sollte, lasst es mich bitte wissen, ansonsten bin ich für absolut jede hilfe dankbar!

    René


  • #2
    Du startest die Scripte auf der php-cli?
    Was sagt pstree zu zu den Prozessen?

    Kommentar


    • #3
      ich starte die scripte in der command-line, ja.
      in pstree sehen die prozesse so aus:
      ├─gnome-terminal─┬─bash─┬─php───6*[php]
      │...........................│............└--3*[php]

      dieser snapshot ist entstanden als das script (bis dahin ohne das problem) auf 7 threads lief.

      /edit: ich merke gerade, dass ich das problem vermutlich erst wieder hervorrufen kann, indem ich neustarte, momentan laufen alle scripts, bei denen es auftritt, fehlerfrei. da ich den rechner momentan aber nicht neustarten kann, weil da ein recht zeitkritischer crawl läuft, könnte ich einen vergleich von pstree zu der situation wo das problem auftritt, erst morgen machen...

      /e2: bessere lesbarkeit.

      Kommentar


      • #4
        use the source[code buttons], luke

        Code:
        ├─gnome-terminal─┬─bash─┬─php───6*[php]
        │                │      └─3*[php]
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          Erstmal das zum fork
          http://de.php.net/manual/de/function...fork.php#99350
          you should be _very_ careful with using fork in scripts beyond academic examples,
          or rather just avoid it alltogether, unless you are very aware of it's limitations.

          the problem is that it just forks the whole php process, including not only
          the state of the script, but also the internal state of any extensions loaded.
          this means that all memory is copied, but all file descriptors are shared among
          the parent and child processes.
          and that can cause major havoc if some extension internally maintains
          file descriptors.
          the primary example is ofcourse mysql, but this could be any extensions that
          maintains open files or network sockets.
          also, just reopening your connection in the parent or child isn't a safe
          method, because when the old connection resource is destroyed, the extension
          might not just close it, but for example send a request to the server to log
          off, making the connection unusable.
          this happens with mysql for example, when php exits - in the following script the query will always fail with "MySQL server has gone away":
          Das du dir (ungewollt) damit racing conditions einhandeln kannst, muss wohl nicht weiter erwähnt werden, kommt halt drauf an, was dein Script erledigt, welche Resourcen es wie verwendet usw.

          In einem Multitaksing OS an den Prozeßprioritäten herumzuschrauben ist ebenfalls eine schlechte Idee, es sei denn, du weisst exakt, was du tust. An den falschen Schrauben gedreht, verkehrt sich der Effekt ganz schnell ins negative. Ich habe schon zu C Zeiten Leute erlebt, die sich mit ihrem "Realtime" Programm auf diese Weise den Rechner lahm gelegt haben.

          Wäre interessant zu erfahren, wie das Laufzeitverhalten ist, wenn du keine weiteren Prozesse forkst und nicht an den Prios rumdoktorst - läuft es dann stabil bei gleichmässiger Auslastung? Gibt es Logs der einzelnen Prozesse (wenn du forkst)? Darüber könntest du evtl. erfahren, ob du in Wettlaufsituationen geraten bist. Wie gut ist das Script gegen solche Eventualitäten abgesichert?
          Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

          Kommentar


          • #6
            hallo und danke für die antworten!

            die risiken bezüglich fork sind mir bewusst, ich habe versucht sämtliche probleme zu vermeiden und das hat auch gut geklappt. das skript ist so strukturiert, dass jeder worker unabhängig terminieren kann und kein teilprozess auf dem ergebnis der anderen beruht. zudem kontrolliere ich im vaterprozess ob die kinder noch existieren, und schließe sie sobald sie fertig gerechnet haben.
            auch das prio-geschraube war nur zu testzwecken.

            allerdings wollte ich mit dem forking nur veranschaulichen wie drastisch die laufzeit ansteigt, das problem tritt _nicht_ nur bei geforkten durchläufen auf. auch wenn es gänzlich ohne diese additionen nur auf einem thread läuft, fällt (mindestens) beim ersten durchlauf des skripts nach einem neustart die auslastung auf einen bruchteil und das skript läuft langsam.

            Kommentar


            • #7
              Zitat von k3kz Beitrag anzeigen
              mir ist bewusst, dass man für solche aufgaben eher andere sprachen verwenden würde, aber php bietet einige funktionalitäten, die ich bspw. unter perl vermissen würde.
              Die da wären?
              Gerade bei CLI-Scripten finde ich Perl unschlagbar, weil es für jeden Mist bereits Module gibt, die man großteils per CPAN-Shell/PackageManager installieren kann.

              Zitat von lstegelitz Beitrag anzeigen
              racing conditions
              YMMD
              actra.development - Zend Certified Engineer for PHP5 - actra-oss @ github

              Kommentar


              • #8
                noch zumal du von RegEx redest .. PERL ist meines Wissens nach nicht die "Mutter" der RegEX aber so eine Art "Königin" ... und geht in diesem Punk wesentlich weiter als PHP (mächtigere Funktionen)
                "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste

                Kommentar


                • #9
                  danke für die antworten!
                  ich weiß, dass viele sachen in puncto commandline-scripting mit perl schnell und einfach zu lösen sind, doch habe ich dieses projekt eben in php begonnen und möchte nun nach 600 zeilen code ungern soviel zeit nur fürs übersetzen in perl aufwenden.

                  zumal ich gerade bei regex die PREG-funktionen von php großartig finde, vgl. preg_match_all: rückgabewert ist die anzahl der matches, es wird gleichzeitig ein mehrdimensionales array mit allen matches und dazu allen matching-gruppen erstellt. das ist meines wissens in perl deutlich umständlicher.
                  perl bietet demgegenüber v.a. vorkompilierung, was natürlich ne menge zeit sparen kann. wohl geschmackssache und v.a. gewöhnungssache.

                  das ist allerdings alles nicht des pudels kern, mir gehts darum, rauszufinden, warum nach einem neustart des rechners der erste durchlauf eines php-scripts mit viel file-IO, stringbearbeitungen und regulären ausdrücken nach ein paar sekunden brutal langsam wird und der prozessor nicht mehr ausgelastet ist. alle weiteren durchläufe sind normal.

                  irgendwer ideen?

                  Kommentar


                  • #10
                    also, danke für die hilfe bis zu diesem punkt. ich habe das problem isolieren können.
                    es hat tatsächlich nichts mit php zu tun offenbar, sondern damit, das file-I/O einfach ziemlich langsam ist. es ließ sich experimentell isolieren, dass weder scandir() noch fopen() lange brauchten, aber das auslesen einer datei (sowohl per fread(), fgets() oder file_get_contents()) beim ersten durchlauf eines scripts nach neustart immens bremst.
                    zudem bestehen die probleme auch in anderen scriptingsprachen (getestet wurden ruby und perl).

                    daraus schließe ich, das ubuntu vermutlich dateisysteme, die von einem prozess genutzt und ausgelesen wurden, auf irgendeine weise precachet oder prefetcht oder sowas. nun würde ich gerne wissen, ob es irgendwie möglich ist, manuell ein prefetch einzuleiten, damit ich mir die quälend langsamen ersten durchläufe gleich sparen kann. kennt jemand also eine möglichkeit, manuell alle dateien aus einem bestimmten ordner vorzucachen?

                    Kommentar


                    • #11
                      Zitat von k3kz Beitrag anzeigen
                      kennt jemand also eine möglichkeit, manuell alle dateien aus einem bestimmten ordner vorzucachen?
                      Evtl. sowas?

                      http://manpages.ubuntu.com/manpages/...sd.conf.5.html
                      Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                      Kommentar


                      • #12
                        das könnte helfen. schau ich mir mal an! danke

                        Kommentar


                        • #13
                          Zitat von k3kz Beitrag anzeigen
                          ein verzeichnis mit zw. 70k und 350k html-dateien
                          Mit zu vielen Verzeichniseinträgen kann das Ext-Dateisystem nicht wirklich gut umgehen.

                          Verteil die Dateien in Unterverzeichnisse so, dass du max. 10-20k Dateien in einem Verzeichnis hast.

                          Grüße.

                          Kommentar

                          Lädt...
                          X