Asterisk -rx kann * lahm legen

[HobbyStern]

Hallo Gemeinde,

kann es sein das massige Zugriffe auf den rx Befehl, womöglich sogar noch parallel - den Asterisk von aussen nicht merh ansprechbar machen können.

Passiert hier aktuell zum zweiten Mal.

Ist das RXen ein Teil des Kernmoduls?

LG Stefan

 

[pce]

Hallo,

wenn die Verbosität höher als 2 ist, dann kommt es bei jeder Verbindung über Unix Domain Sockets zu 2 (öffnen/schliessen) Warnungen.

Das Maximum liegt bei 128 simultane Verbindungen (default).

Ist das RXen ein Teil des Kernmoduls?

Ist zuminmdest in asterisk.c und wenn so viel remote (-rx/-r) ausgeführt wird, würde ich, wenn die Möglichkeit besteht, einfach die Warning "Remote Unix Connection" patchen, also beispielsweise "if (option_verbose > 2)" höher setzen oder wenn es kein Performanceproblem ist, das Maximum höher setzen (AST_MAX_CONNECTS).

 

[HobbyStern]

Hi pce,

ich hatte v 3 , habs mal auf v 1 gesetzt.

Interessant war diese Konfigzeile : (asterisk.conf)

hideconnect = yes ; Hide messages displayed when a remote console connects and disconnects

Habs mal auf YES (s.o.) gestellt.

Mehr als 128 Verbdg. sollten nicht eingehen, maximal 20.

Ich warte das ganze mal ab. Dank Dir!

Stefan

 

[HobbyStern]

Hallo pce und alle Mitlesenden,

das Problem besteht trotz Verbose = 1 noch immer.

Beim letzten "Einkapseln" - dann abstürzen tut er ja nicht (das wäre ja einfacher aufzufangen) war es der 15.12.2010 um 11:40 - Aktionen die dort liefen waren mir leider unbekannt (Verbose 1 halt..)

Ich habe es jetzt gerade gemerkt...:-(

Naja..

LG Stefan

 

[pce]

das Problem besteht trotz Verbose = 1 noch immer.

Hi HobbyStern,

sind die Remote Connects gleichzeitig?

Was wird ausgeführt, dass /etc/init.d/safe_asterisk ?

ich habe mal bei VoIP-info gelesen, dass bei zuvielen gleichzeitigen Remote Befehlen
jemanden der asterisk crashde (monitoring).

In meinem trivialen Test (*) konnte ich simultan 42 Remotebefehle absetzen,
habe das mit ps & top & in der cli kontrolliert,
ein Call dazu abgesetzt und die CPU verhielte sich nicht auffällig.

Es kommt natürlich auch darauf an was ausgeführt und wie lange asterisk damit beschäftigt ist.
Wenn man es nachstellen kann, könnte man einen kleinen Test schreiben.


(*)(einfach jede Menge shellskripts mit & (im Hintergrund) aufgerufen, welche mehrmals ein Skript aufrufen, das den remote Befehl ausführt.)

 

[HobbyStern]

Hallo pce,

das ist eine gute Idee - ich werde * mal einem StressTest unterziehen.

Die Remote Befehle können sehr wohl gleichzeitig sein - ich setze datenbank einträge in der astdb - nichts wildes, zBsp. setze ich eine "40" oder eine "20" oder oder - durchaus auch gleichzeitig. Safe_Asterisk wird eingesetzt (im Shell-Skripte Bereich habe ich meine modifizierte Version gepostet - ich lasse da als Workaround alle 15 Minuten asterisk rx ausführen, bekomme ich ein "Cant connect" zurück lasse ich den Asterisken beenden, aber zu diesem Zeitpunkt bekomme ich ihn nur schwer noch mit einem einfachen kill in den Griff. Jedoch ist er voll funktionsfähig - nur die CLI versagt absolut.)

Ich habe die Verbosity erstmal wieder hochgeschraubt - so sollte ich das nächste Mal wieder nachvollziehen können..

Umgehen könnte ich die andauernden rx-e wenn ich in die astdb anderweitig (ohne rx) schreiben könnte, oder dem asterisken channel variablen übergeben würde...aber es muss doch so auch gehen?!

LG Stefan

 

[pce]

Umgehen könnte ich die andauernden rx-e wenn ich in die astdb anderweitig (ohne rx) schreiben könnte

Ja das wäre praktisch, wenn man z.B. wie bei MySQL, mehrere Befehle mit einem Inputfile "reinleiten" könnte (

asterisk -r < cmds.in

) oder die astdb auch direkt ansprechen könnte.

 

[HobbyStern]

Stimme ich Dir zu - eine direkt Anbindung meines statischen! Asterisk an eine MySQL Datenbank - das wäre was, aber ich bin nicht wirklich ein realtime Fan und IMHO benötige ich das auch nicht...

Naja - muss halt rx ein wenig überprüft werden..!
EDIT

Stresstest vorüber, 50 gleichzeitige Datenbank Updates und auslesungen - nix passiert was auffällig wäre...

LG Stefan