Hello,
str_str function searches for a substring into a bigger string.
str_str function in lib/cds/sstr.c file has a comment: /* FIXME:
reimplement using better algorithm */
Attached patch reimplements that function using
Boyer-Moore-Horspool-Raita algorithm, which is the one most text editors
use to search for substrings.
Boyer-Moore-Horspool-Raita algorithm is a simplification from
Boyer-Moore one, with less preprocessing overhead.
If n is the string length, and m is substring length, naive brute force
algorithm has a cost of O(n*m).
Raita algoritm has same cost in worst case but Ω(n/m) a better average cost.
As a drawback it adds a preprocessing cost of O(m + charset_length)
where charset_length is 256 for us, because we use char.
Another way to approach this substring search issue would be separate it
into two functions, a preprocessing one, and a searching one. Then in
module initializacion where the function is used, calculate the needed
preprocess and when the function is called do the search only.
This Raita algorithm could also be useful for str_search function in
ut.c. Its usefulness depends on n, and m lengths, the bigger they are
the better the algoritm works.
http://en.wikipedia.org/wiki/String_searching_algorithmhttp://en.wikipedia.org/wiki/Boyer%E2%80%93Moore%E2%80%93Horspool_algorithmhttp://www-igm.univ-mlv.fr/~lecroq/string/node22.html
Regards,
Vicente.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#236 - Kamailio crash when about 300,000 tls connections opened.
User who did this - Andrei Pelinescu-Onciul (andrei)
----------
You could try also forcing kamailio/ser to pre-fault all the shm memory pages on startup and to lock the pages in memory (shm_force_alloc = yes and mlock_pages = yes in the .cfg). This way you would see on startup if there is enough memory for your shared memory requirements and you will make also all the shared memory unswapable (better performance if it's a dedicated k machine).
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=236#comment690
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#236 - Kamailio crash when about 300,000 tls connections opened.
User who did this - Klaus Darilion (klaus3000)
----------
See http://www.win.tue.nl/~aeb/linux/lk/lk-9.html section "9.6 Overcommit and OOM"
Since 2.5.30 the values are: 0 (default): as before: guess about how much overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise about the overcommit - never commit a virtual address space larger than swap space plus a fraction overcommit_ratio of the physical memory. Here /proc/sys/vm/overcommit_ratio (by default 50) is another user-settable parameter. It is possible to set overcommit_ratio to values larger than 100. (See also Documentation/vm/overcommit-accounting.)
Thus, you have to set it to "2", any maybe also tweak /proc/sys/vm/overcommit_ratio
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=236#comment689
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#236 - Kamailio crash when about 300,000 tls connections opened.
User who did this - Shaobin.Feng (saxon_leo)
----------
thanks for quick reply.
Something really confuse me.
According to top info while connections achieve 310,000, there are almost 3G cached,why OS didn't use them?
And the server overcommit_memory=0,why someone can invoke oom-killer?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=236#comment688
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.