14 Mar
2013
14 Mar
'13
4:27 p.m.
Hi,
in kamailio 3.3 the presence DB mode parameters "subs_db_mode",
"publ_cache" and "notifier_processes" control how the module stores
presentity and watcher info in DB.
If they have been set to the following values:
subs_db_mode=3
publ_cache=0
notifier_processes=3
the following query is executed >10 times/second (mysql log):
"select presentity_uri,callid,to_tag,from_tag,event from
kamailio_active_watchers where updated=123 AND
event<>'presence.winfo'"
According to the notifier_poll_rate default value (==10) and the formula
in the documentation
1/(waitn_time * notifier_poll_rate * notifier_processes)
That results in 1/(5*10*3) == 1/150
So is it really regular behaviour, if the query is performed that often?
What about using triggers in that situation?
Additionally I have noticed, that only one subscriber gets notified, if
a presentity changes although all subcribers have been stored correctly
in active_watchers.
When I set notifier_processes to 0 (old behaviour) every subscriber gets
notified correctly...
Cheers
Jasmin
14 Mar
14 Mar
5 p.m.
Hello,
When you are using the notifier processes the presence module needs to
check the database to see if any records have been marked as requiring
notification. The rate of these checks is fixed and has nothing to do
with the number of subscribers on the system. This is by design so as
to evenly distribute the processing for notification across time.
Each database query checks a subset of the records (based on a hash).
This size of this subset depends on the modparam settings used. With
the other notifier process modparams and the three notifier processes
you have configured the records have been split into 150 subsets and
each process checks 10 of the subsets per second (for a total of 30
database queries per second).
As for the not all subscribers being notified, assuming everything (your
Kamailio configuration, client configuration, and so on) is correct it
could well be a bug. The notifier processes rely on features only
available in Kamailo 4.0.0 (to do with database transaction handling and
locking) to work correctly. Also, these database features in Kamailio
4.0.0 are only currently available in the Kamailio PostgreSQL database
driver. I would not expect this to work properly unless you are using
Kamailio 4.0.0 with PostgreSQL.
Regards,
Peter
On 14/03/13 15:27, Jasmin Schnatterbeck wrote:
Hi,
in kamailio 3.3 the presence DB mode parameters "subs_db_mode",
"publ_cache" and "notifier_processes" control how the module stores
presentity and watcher info in DB.
If they have been set to the following values:
subs_db_mode=3
publ_cache=0
notifier_processes=3
the following query is executed >10 times/second (mysql log):
"select presentity_uri,callid,to_tag,from_tag,event from
kamailio_active_watchers where updated=123 AND
event<>'presence.winfo'"
According to the notifier_poll_rate default value (==10) and the
formula in the documentation
1/(waitn_time * notifier_poll_rate * notifier_processes)
That results in 1/(5*10*3) == 1/150
So is it really regular behaviour, if the query is performed that often?
What about using triggers in that situation?
Additionally I have noticed, that only one subscriber gets notified,
if a presentity changes although all subcribers have been stored
correctly in active_watchers.
When I set notifier_processes to 0 (old behaviour) every subscriber
gets notified correctly...
Cheers
Jasmin
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5:07 p.m.
New subject: massive SQL load and one subscriber only with presence 3.3 - mySQL help needed!
14 mar 2013 kl. 17:00 skrev Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>om>:
Also, these database features in Kamailio 4.0.0 are
only currently available in the Kamailio PostgreSQL database driver. I would not expect
this to work properly unless you are using Kamailio 4.0.0 with PostgreSQL.
Which is why we need all the MariaDB/MySQL developers on this list to step forward and
join us in fixing this in the MySQL driver (and possible other db_* drivers too).
Thank you for helping out!
/O
4250
days inactive
4250
days old
2 comments
3 participants
participants (3)
-
Jasmin Schnatterbeck -
Olle E. Johansson -
Peter Dunkley