1 Jun
2018
1 Jun
'18
12:27 a.m.
PS. As a general rule of thumb, the size (in terms of buckets) of the
htable should be at least 2x the maximum number of entries you expect to
put in it, and the bigger the better.
Hash tables are inherently inefficient in that regard; it would require
a perfect hash algorithm and a perfect variance in keys to get unique
bucket hits in a situation where size(htable) =~ entry count N.
On Thu, May 31, 2018 at 05:22:43PM -0400, Alex Balashov wrote:
Hi,
I might be mistaken in my interpretation of the situation, but my first
guess would be multiple entries ending up in the same slot is simply a
reflection of some values being hashed to the same bucket. Hash table
implementations usually deal with collisions by implementing a linked
list attached to the bucket/slot, and search algorithms will traverse
that list linearly looking for an exact key match. The general
expectation is that collisions won't be too common and that the average
depth of a collision chain will be low.
If this is the case, increasing the size of the htable will help. What
is the value of the 'size' parameter for that htable definition now?
-- Alex
On Thu, May 31, 2018 at 08:07:18PM +0000, Brooks Bridges wrote:
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Apologies if the initial report was unclear. The
issue isn't with the actual counts (which appear to be accurate), but that we are
intermittently ending up with 2 keys in the same entry instead of one per entry.
This makes parsing the data very difficult, and I cannot determine a reason it would be
doing this instead of putting each one in its own entry like it appears to do for almost
all of the values until it has run for a while.
Brooks Bridges | Engineering Manager
O1 Communications
4359 Town Center Boulevard, Suite 217
El Dorado Hills, California 95762
office: 916.235.2097 | main: 888.444.1111, Option 2
email: bbridges@o1.com<mailto:bbridges@o1.com> | web:
www.o1.com<http://www.o1.com/>
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
Sent: Thursday, May 31, 2018 12:52
To: Kamailio (SER) - Users Mailing List; Brooks Bridges
Subject: Re: [SR-Users] Strange behavior with $shtinc
Did you monitor the values of those statistics over the time? If yes, was there a moment
when the value evolved unexpected?
Cheers,
Daniel
On 31.05.18 19:30, Brooks Bridges wrote:
Let me preface this with the statement that as best I can tell from docs and code, this
function is supposed to be 100% atomic and this shouldn't be able to happen. I also
have not found anything in the module's github commit logs that would indicate this
behavior has changed from previous versions.
That being said, I appear to have run into an oddity where intermittently I'm getting
2 slots being put in the same entry, which results in trying to parse the output for
graphing and reporting not working quite right. The mechanism I'm using is a very
simple counter mechanism to record statistics about calls. As an example, I am using the
following mechanism:
$var(z) = $shtinc(callstats=>$avp(realm),cps_exceeded);
or
$var(z) = $shtinc(callstats=>$avp(realm),sessions_exceeded);
This typically results in something like this:
{
entry: 4335
size: 1
slot: {
{
name: realm1,total_requests
value: 2365034
type: int
}
}
}
{
entry: 4532
size: 1
slot: {
{
name: realm2,cps_exceeded
value: 30
type: int
}
}
}
And so on... However, one or more of them sometimes end up like this:
{
entry: 4646
size: 2
slot: {
{
name: realm1,total_requests
value: 15958026
type: int
}
{
name: realm2,cps_exceeded
value: 6432103
type: int
}
}
}
Thanks in advance for your help and/or suggestions!
Brooks Bridges | Engineering Manager
O1 Communications
4359 Town Center Boulevard, Suite 217
El Dorado Hills, California 95762
office: 916.235.2097 | main: 888.444.1111, Option 2
email: bbridges@o1.com<mailto:bbridges@o1.com> | web:
www.o1.com<http://www.o1.com/>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com<http://www.kamailioworld.com>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users