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: > 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: [email protected]<mailto:[email protected]> | web: > www.o1.com<http://www.o1.com/> > > From: Daniel-Constantin Mierla [mailto:[email protected]] > 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: [email protected]<mailto:[email protected]> | web: > www.o1.com<http://www.o1.com/> > > > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected]<mailto:[email protected]> > > 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 > [email protected] > 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 [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
