Asterisk on FBF: Ein Asterisk-Prozess braucht 95% CPU

[udosw]

Wie ich schon geschrieben hatte, läuft * auf meiner 7050 mit aktiviertem WLAN. Nach der ersten erfolgreichen Installation hatte ich schon einmal das Problem mit hoher CPU-Last, da hatte es sich auch akustisch bemerkbar gemacht: MoH stotterte deutlich.

Nach Neustart war das Problem aber ohne Konfigurationsänderung erstmal vorbei. Heute morgen war 'äußerlich' kein Unterschied zu merken: MoH lief flüssig. Trotzdem zeigte top:

Mem: 28160K used, 2176K free, 0K shrd, 2860K buff, 9660K cached
Load average: 2.04 2.04 1.78
    PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
   3906 root     R        908  3905 94.5  2.9 asterisk
   2709 root     S       1216     1  3.5  4.0 multid
    317 root     R        392  3969  1.7  1.2 top
   3900 root     S       3416  3894  0.0 11.2 asterisk
   3893 root     S       3416     1  0.0 11.2 asterisk
   3907 root     S       3416  3894  0.0 11.2 asterisk
   3901 root     S       3416  3894  0.0 11.2 asterisk
   3899 root     S       3416  3894  0.0 11.2 asterisk
   3898 root     S       3416  3894  0.0 11.2 asterisk
   3897 root     S       3416  3894  0.0 11.2 asterisk
   3894 root     S       3416  3893  0.0 11.2 asterisk
   3896 root     S       3416  3894  0.0 11.2 asterisk
    630 root     S N     2032     1  0.0  6.6 ctlmgr
[...]

Na, dann schieß' ich den mal ab, dachte ich mir :

  / $ kill 3906
  / $ top
Mem: 27752K used, 2584K free, 0K shrd, 2860K buff, 9660K cached 
Load average: 1.92 2.02 1.81
    PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
    319 root     R        352  3969  6.4  1.1 top
   2709 root     S       1216     1  5.5  4.0 multid
   3900 root     R       3396  3894  0.0 11.1 asterisk
   3893 root     S       3396     1  0.0 11.1 asterisk
   3901 root     S       3396  3894  0.0 11.1 asterisk
   3899 root     S       3396  3894  0.0 11.1 asterisk
   3898 root     S       3396  3894  0.0 11.1 asterisk
   3897 root     S       3396  3894  0.0 11.1 asterisk
   3894 root     S       3396  3893  0.0 11.1 asterisk
   3896 root     S       3396  3894  0.0 11.1 asterisk
    630 root     S N     2032     1  0.0  6.6 ctlmgr

Das für mich Verblüffende: Der Asterisk funktioniert weiter einwandfrei . Wie kann das sein, dass sich ein scheinbar unabhängiger *-Prozess 'abspaltet' und vor allem: Wie kann man das verhindern?

Udo

 

[bodega]

Hallo Udo,

das Problem kommt mir bekannt vor (zwar nicht bei Asterisk aber bei anderer Telefon-Software).

Startest du den * aus der debug.cfg heraus? Wenn dem so ist, probiere mal ein 'sleep 60' vor dem Start des Asterisk. Eventuell geht auch eine kürzere Wartepause...

Wenn es aber im laufenden Betrieb passiert, bin ich etwas ratlos..

 

[spblinux]

@udosw:
die process id Werte, PID und PPID (=parent PID), sprechen gegen die Vermutung von bodega.

Der 95% cpu Prozess ist erst viel später von einem asterisk thread (3905), der bereits nicht mehr existiert, gestartet worden.

Ist wohl ein Kandidat für asterisk -rvvv[vvvvvvvllllllllllll] im Terminal-Fenster bzw. dafür dass man asterisk in eine log-Datei schreiben lässt.

Gruss, spblinux

 

[udosw]

Ist wohl ein Kandidat für asterisk -rvvv[vvvvvvvllllllllllll] im Terminal-Fenster

Stimmt, hatte ich inzwischen auch rausbekommen. Der sieht bei mir so aus:

 3442 root       1032 S   rasterisk sk -vvvr

Etwas komisch, finde ich. Ich rufe die CLI so auf:

/var/chroot /var/asterisk14 bin/asterisk -vvvr

Wenn ich es so mache:

cd /var
./chroot asterisk14 /bin/asterisk -vvvr

sieht der Prozess so aus:

 3558 root       1032 S   rasterisk isk -vvvr

Stimmt da was mit dem chroot nicht?
Und wie kommt es zu der hohen CPU-Last?

Gruß, Udo

 

[spblinux]

Ich spiele mal Orakel:
- bei gewissen dialplan Aktionen macht der * neue Threads auf
- wenn es jetzt eine schöne Endlosschleife in dieser Aktion hat, dann beginnt der fritzbox cpu burnin Prozess.
- die Schleife könnte direkt im dialplan sein (wohl eher nicht??)
- die Schleife kann auch ein bug von * bei speziellen Aktionen sein (evt. im download Bereich von digium.com mal das changelog von 1.4.4 auf 1.4.5 anschauen)

Solange unbekannt ist, bei welcher dialplan Aktion der cpu-fressende Thread geöffnet wird, gilt ???

Gruss, spblinux

PS: was soll denn an den beiden chroot Aufrufen nicht in Ordnung sein?
(/var/chroot /var/asterisk14 asterisk -..... reicht auch)

Korrektur: statt -vvvvvlllll muss es -vvvvvdddd heissen
Ist aber auch auf der *-Konsole per set verbose N bzw. set debug N (N=0...10) einstellbar.

 

[udosw]

Solange unbekannt ist, bei welcher dialplan Aktion der cpu-fressende Thread geöffnet wird, gilt ???

Hmm, an eine Dialplan-Aktion glaube ich eigentlich nicht. Die eigentlichen Asterisk-Prozesse verhalten sich ja immer ganz ruhig. Der Prozess, der die CPU-Last macht, ist ja nur die Konsole (wenn sie länger offen ist).

PS: was soll denn an den beiden chroot Aufrufen nicht in Ordnung sein?

Ich meine die komische Anzeige der Prozesse:

3442 root       1032 S   rasterisk [B][COLOR=Red]sk[/COLOR][/B] -vvvr
3558 root       1032 S   rasterisk [COLOR=Red][B]isk[/B][/COLOR] -vvvr

je nachdem wie man es startet.

Ich lasse heute nacht mal die CLI in einem Terminalfenster offen, mal sehen was passiert.

Udo

 

[udosw]

Ich lasse heute nacht mal die CLI in einem Terminalfenster offen, mal sehen was passiert.

Nichts ist passiert, aber jetzt weiß ich was das Problem ist: Ich habe jetzt das Terminalfenster, in dem ich die CLI anzeigen ließ, geschlossen, ohne die CLI zu schließen: Das erzeugt dann 95% CPU-Last auf dem einen Prozess.
OK, das lässt sich leicht verhindern, wenn man aufpasst. Trotzdem komisch, denn auf anderen Linuxen kenne ich so ein Verhalten nicht.
Udo

 

[spblinux]

@udosw:
nach obigem ist es vermutlich die busybox 1.4.1 vom dsmod die für all diese Phänomene verantwortlich ist.

sk, isk müsste in der busybox Dokumentation stehen, was der Unterschied ist; (rasterisk erscheint bei mir auch).

Ärger mit sich nicht richtig schliessenden/beendenden Terminalfenstern ist bereits öfter hier im Forum aufgetaucht und liegt meines Wissens an der busybox (ich meine auch bei anderen Versionen als 1.4.1 schon der Fall gewesen).

Vermutlich kann damit ein - GELÖST in den Titel dieses Threads.

Gruss, spblinux

 

[olistudent]

Okay. Im ds26-15 ist die busybox-1.5.1 drin und auch ein Patch der dieses Problem hoffentlich behebt.

MfG Oliver

 

[udosw]

OK, ich konnte inzwischen auch hohe CPU-Last bei anderen Prozessen beobachten, wenn ich das betr. Terminalfenster geschlossen hatte.
Wo gibt's den neuen ds-mod?
Udo

 

[olistudent]

Noch gar nicht. Hatte ich vergessen zu erwähnen. ;-)

MfG Oliver

 

[MaxMuster]

Wo gibt's den neuen ds-mod?

Vielleich irre ich mich ja, aber wenn ich Alexander hier richtig verstanden habe, sollte das Problem schon im ds26-14.4 behoben sein. Der Patch dazu steht übrigens auch da in Post 25:

--- shell/ash.c.ori     2007-01-24 22:34:40.000000000 +0100
+++ shell/ash.c 2007-04-29 15:40:44.000000000 +0200
@@ -6560,7 +6560,9 @@
                /* turning job control off */
                fd = ttyfd;
                pgrp = initialpgrp;
-               xtcsetpgrp(fd, pgrp);
+               /* was xtcsetpgrp, but this can make exiting ash
+                * with pty already deleted loop forever */
+               tcsetpgrp(fd, pgrp);
                setpgid(0, pgrp);
                setsignal(SIGTSTP);
                setsignal(SIGTTOU);

Jörg

EDIT: Steht sogar im ersten Beitrag zum 14.4-er dsmod:

Die alten Probleme mit der Busybox-Shell 100% Auslastung, wenn ssh-Client nicht mit exit beendet wird sowie nicht schließendes Putty bei Telnet-Verbindung trotz reguläres exits) sind behoben....

 

[udosw]

sollte das Problem schon im ds26-14.4 behoben sein.

Also das ist es IMHO nicht:

BusyBox v1.4.1 (2007-06-13 19:38:49 CEST) Built-in shell (ash)
[I] [ich schließe anderes Terminalfenster mit CLI][/I]
[B] $ top[/B]
Mem: 28292K used, 2044K free, 0K shrd, 2272K buff, 8488K cached
Load average: 0.62 0.22 0.12
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
 3505 root     R       1036  3504 90.0  3.4 asterisk
...
[B] $ ps ax[/B]
...
3505 root       1036 R   rasterisk sk -vvvr 
...

Gute Nacht :-Ö
Udo

 

[MaxMuster]

Also das ist es IMHO nicht

Puh, gut das ich den Konjunktiv genutzt hatte. Ich war davon ausgegangen, dass die "SSH-Probleme" die gleiche Ursache hatten, denn die sind nun behoben.
[Verteidigung]
Allerdings habe ich mich auch ein wenig von der Signatur irreführen lassen und nur das ds-0.2.9_26-14 gesehen und auf einen älteren mod als ds26-14.4 geschlossen....
[/Verteidigung]
Aber man soll es sich ja nicht mit den Moderatoren verderben ;-)

Schönet Tag!

Jörg