Reduzierung der CPU Load beim HTML-Parsen

[tupol]

Hallo Perl-Spezialisten,

ich habe ein Problem mit dem Perl-Modul HTML::Parser.

Es muss in einem abgespaltenen Prozess (BlockingCall) mehrere Dateien von ca. 0,5 MByte auswerten und erzeugt in dieser Zeit eine CPU-Load von 100% (auf der Raspberry Pi) und damit einen Stillstand von FHEM.

Weiß jemand, wie man das in den Griff bekommen kann?

Gruß

tupol

[rudolfkoenig]

Ich sehe mehrere Moeglichkeiten
- schnelleren Hardware, z.Bsp. RPi-2
- auf das Modul verzichten, und selbst parsen
- sich einreden, dass 100% CPU  gar nicht so schlecht ist.

FHEM sollte nicht stillstehen, wenn die Aktivitaet in BlockingCall ausgefuehrt wird, es sei denn die Platte ist extrem belastet.

[justme1968]

- mit nice die priorität des geforkten prozesses runtersetzen und schauen ob es hilft.

gruß
  andre

[tupol]

- mit nice die priorität des geforkten prozesses runtersetzen und schauen ob es hilft.

OK. Wie mach ich das genau. Habe im Netz nichts dazu gefunden.

[justme1968]

du kannst in der aufgerufenen funktion als erstes entweder

Code Auswählen Erweitern

setpriority( 0, 0, 10) aufrufen oder

Code Auswählen Erweitern

nice( 10 );für nice brauchst du noch ein

Code Auswählen Erweitern

use POSIX qw(nice);

beides sollte die priorität des geforkten prozesses runter setzen.

du kannst mit dem 10 spielen. mögliche werte liegen zwischen 1 und 19 (bzw. 20). negative werte würden die priorität erhöhen. das geht aber nur als root.

ob es in deinem fall hilft musst du natürlich auch schauen.

das ganze gibt es so nur unter unix/linux systemen.

gruss
  andre

[tupol]

Hmm. So richtig hat es nicht funktioniert aber ich lasse setpriority trotzdem erstmal drin, weil es theoretisch Sinn macht. Nicht Linux-Systeme bekommen doch jetzt keinen Fehler. Oder?

Ich habe mal etwas rumprobiert und ein regelmäßiges usleep(1000) eingebaut. Dann dauert der Prozess etwa doppelt so lange (30 s), aber anscheinend entlastet es die CPU. Bin mir aber nicht sicher, ob das wirklich sinnvoll ist. 

[justme1968]

wenn nice nicht hilft ist es vermutlich nicht die cpu die der engpass ist.

wie ist die verteilung der auslatung auf user/system/waiting? was sagt top dazu?


das sleep im geforkten prozess sollte keine probleme machen. wenn io der engpass ist lässt das sleep eventuell eher raum für die anderen prozesse als das nice.

[tupol]

htop sagt, dass der gegabelte Prozess zu den 100% führt. Alle Prozesse laufen mit PRI 20 NI 0. Der gegabelte nun mit PRI 30 NI 10.

Ich könnte mir deshalb vorstellen, dass nun die anderen Prozesse "überholen" dürfen und die 100% nicht mehr so schlimm sind.

Eigentlich bin ich auf der Suche nach dem Prozess, der regelmäßig meine HMLAN "disconnected". So wie ich es verstanden habe, ist die sehr empfindlich gegen hohen CPU-Lasten. Das Modul war es aber anscheinend nicht. Jetzt suche ich weiter.

[justme1968]

ja. so in etwa wirkt sich das nice aus.

das 'normale' top zeigt dir in der cpu zeile user,system,nice,idle und waiting. die verteilung hier kann dir hinweise geben.

wenn z.b. waiting einen deutlichen anteil hat ist deine platte/sd karte bzw der zugriff darauf das problem und du musst hier ganz anders ran gehen.

auch das verhälniss von user zu system kann zeigen das es nicht die eigenen berechnungen sind.


wenn es fhem intern ist: hast du schon apptime probiert?