Fixed in 71a88212 - please re-open if the issue remains after testing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #822.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/822#event-1020940437___
sr-dev mailing list
sr-dev@lists.sip-router.org
Yes, I would be happier implementing that way, since the lock method is better
in most situations.
If no-one has any objections or reasons not to, then I shall proceed on that
basis and make the necessary changes this evening.
--
You are receiving this because you are subscribed to this
I am not sure if removing the lock/mutex is the proper solution here, as I
didn't analyze the module properly, so it might be better to make it optional
via modparam to run in old mode with locks and new mode with sleep. I guess it
should not be that complex, given that the new patch is rather
Thanks, @tombeard - it works and appears safe. However, in my own (Centos)
tests, CPU utilisation when workers are idle is noticeably higher than before.
Increasing the sleep duration helps - so if it is implemented this way then it
should be exposed as a mod param with a sensible default.
@charlesrchance ignoring my second comment, I think that probably is safe.
Either way, there's a pull request for testing / fixing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ok, I'll refine and push for testing tomorrow. Thanks for the input @tombeard.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@tombeard thanks - I guess not! Pull request?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/822#issuecomment-289914479___
sr-dev
@charlesrchance okay, after pressing send I see the obvious flaw in that, but
it solves the problem in my specific situation with a single worker thread.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@charlesrchance do you need a lock at all?
https://github.com/tombeard/kamailio/commit/310c0f91858a6baf4b17a00798689f7f1f6acaa1
No idea how this performs on other platforms or in other situations, but for my
specific requirement it solves the high cpu condition on FreeBSD waiting for
lock
Revisiting this now after a busy few months.
@miconda - is it better in your opinion to introduce new locking method
completely, or only in the presence of a compile-time flag?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Any progress?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/822#issuecomment-276957993___
sr-dev mailing list
Thanks, @miconda, will take a look.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/822#issuecomment-259144332___
sr-dev mailing list
Got deadlock (?) on latest build of kamailio:
version: kamailio 5.0.0-dev6 (x86_64/freebsd)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, FAST_LOCK-ADAPTIVE_WAIT,
Apologies, I have been away for a couple of weeks. DMQ does indeed use mutexes
to trigger processing of a new task by its workers.
Your log shows everything is as expected with DMQ - i.e. with no other traffic,
a lock is acquired/released once every minute with each peer notification (node
On another one build I tried to enable POSIX semaphores, but problem still
exists.
Compiler change also didn't help.
```
root@kamailio-c1:/var/log# kamailio -V
version: kamailio 5.0.0-dev6 (x86_64/freebsd) 580670
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
Kamailio is using spin locks (for mutexes) and that can cause high cpu on some
systems. I am not very familair with dmq internals, but it looks like it uses
mutexes to trigger the presence of a new task for its worker processes, meaning
that a worker stays in mutex-get operation (spinning),
Hi all!
We trying to use two instances of kamailio on FreeBSD, kamailio was build from
master branch.
If I enables DMQ, 2 threads (pids) start utilize CPU, less than minute it's up
to 100% (on a both servers).
At that time kamailio successful handle calls, dmq and usrloc replication wokrs
fine.
18 matches
Mail list logo
