Daniel-Constantin Mierla writes:
> The mysql client library is stuck, waiting for a poll event to happen.
> It is the insert done for accounting on SIP response.
>
> It is hard to say what is the reason, maybe you can install the debug
> symbols for lib mysql client library and the the backtrace
On 03.09.19 10:53, Daniel-Constantin Mierla wrote:
> On 03.09.19 09:54, Juha Heinanen wrote:
>> Juha Heinanen writes:
>>
>>> Here is two traps taken about 8 minutes apart during the same freeze:
>>>
>>> https://box.tutpro.com/tmp/gdb_kamailio_20190902_120249
>>>
On 03.09.19 09:54, Juha Heinanen wrote:
> Juha Heinanen writes:
>
>> Here is two traps taken about 8 minutes apart during the same freeze:
>>
>> https://box.tutpro.com/tmp/gdb_kamailio_20190902_120249
>> https://box.tutpro.com/tmp/gdb_kamailio_20190902_121032
>>
>> During the freeze, it was
Juha Heinanen writes:
> Here is two traps taken about 8 minutes apart during the same freeze:
>
> https://box.tutpro.com/tmp/gdb_kamailio_20190902_120249
> https://box.tutpro.com/tmp/gdb_kamailio_20190902_121032
>
> During the freeze, it was possible to make MySQL queries to accounting
> table
Hello,
is still blocked? Can you get a second trap cmd output? I want to
compare with another output taken later if still blocked.
I see a process blocked on a mysql insert query on acc_onreply() and
other processes wait for the same lock.
Cheers,
Daniel
On 02.09.19 10:22, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> If you have access to the system when that blocks in this way during
> that interval, take the output of 'kamctl trap' or the backtrace with
> gdb for a sip udp worker process.
Got trap of all processes. Placed it here:
Daniel-Constantin Mierla writes:
> That's why backtrace would help to see where the processes are stuck.
Thanks for your comments. Backtrace will be taken during next freeze.
-- Juha
___
Kamailio (SER) - Users Mailing List
On 29.08.19 13:02, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Being reply processing, one potential operation that can be slow is
>> writing the acc record to the database. Any external tool blocking the
>> acc tables?
> I'm not sure about that. Unfortunately there was no SIP
Normally it should report an error (if the database supports it):
https://www.kamailio.org/docs/modules/5.2.x/modules/db_mysql.html#idm1051351308
For library reasons this is in the seconds time range.
Cheers,
Henning
Am 29.08.19 um 13:02 schrieb Juha Heinanen:
> Daniel-Constantin Mierla
Daniel-Constantin Mierla writes:
> What is the version? Practically kamctl trap is wrapping around gdb
> batch commands to get the backtrace of all kamailio processes.
I found it.
-- Juha
___
Kamailio (SER) - Users Mailing List
Daniel-Constantin Mierla writes:
> Being reply processing, one potential operation that can be slow is
> writing the acc record to the database. Any external tool blocking the
> acc tables?
I'm not sure about that. Unfortunately there was no SIP over TCP calls
during the UDP freeze so that
On 29.08.19 10:36, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> If you have access to the system when that blocks in this way during
>> that interval, take the output of 'kamctl trap' or the backtrace with
>> gdb for a sip udp worker process.
> Didn't find 'kamctl trap', will try
Being reply processing, one potential operation that can be slow is
writing the acc record to the database. Any external tool blocking the
acc tables?
Cheers,
Daniel
On 29.08.19 10:26, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Can you see what is the next debug message
Daniel-Constantin Mierla writes:
> If you have access to the system when that blocks in this way during
> that interval, take the output of 'kamctl trap' or the backtrace with
> gdb for a sip udp worker process.
Didn't find 'kamctl trap', will try gdb.
-- Juha
Daniel-Constantin Mierla writes:
> Can you see what is the next debug message printed by pid 19674?
Below is a few lines of the process before the freeze and a few after
(freeze took this time about 13 minutes). Looks like the process
resumed processing of the same sip request.
> If you have
Can you see what is the next debug message printed by pid 19674?
If you have access to the system when that blocks in this way during
that interval, take the output of 'kamctl trap' or the backtrace with
gdb for a sip udp worker process.
Cheers,
Daniel
On 29.08.19 08:50, Juha Heinanen wrote:
>
Joel Serrano writes:
> Did you check to see if UDP packets (maybe?) are being queued at the
> network level before reaching K?
Thanks for the tip. Will check next time ($ ss -4 -n -l | grep 5060).
-- Juha
___
Kamailio (SER) - Users Mailing List
Hi Juha,
Did you check to see if UDP packets (maybe?) are being queued at the
network level before reaching K?
You should be able to see that with netstat, not that this fixes the
problem but might point in some direction...
On Tue, Aug 27, 2019 at 9:29 AM Juha Heinanen wrote:
> Juha
18 matches
Mail list logo
