[sr-dev] changing behavior in db_text

Daniel-Constantin Mierla miconda at gmail.com
Fri Jan 6 11:32:23 CET 2017


Hello,


ok, I see the limitation and should be fixed in a way or another, even
for 5.0. But maybe is better to use the system memory in this case, the
shared memory requires locking and I don't see it's necessary in this
case. Actually same happens with the mysql (or other db backends), they
fetch the result in system memory and then our modules convert what's
needed to pkg memory. db text has the lib embedded and that part can use
system malloc.


My suggestion is to define some aliases to memory functions, like
dbt_malloc/dbt_free/..., pointing them to malloc/free/... or
pkg_malloc/pkg_free/... based on a compile time flag and set it to the
system malloc via module Makefile. Same is done by ctl module, which can
be used as example, see: src/modules/ctl/ctl.h .


Cheers,
Daniel


On 05/01/2017 18:19, Luis Azedo wrote:
>
> Hi All,
>
>
> db_text modules manages the tables data in shm_mem
>
> db_text module uses pkg_mem to store query results which leads to some
> problems.
>
>
> when we have large text files with a lot of rows (location,
> active_watchers, presentity), the startup procedure fetches all the
> records, which makes db_text copy all records from shm_mem to pkg_mem,
> leading to memory failures.
>
>
> i now have a patch that changes this behaviour.
>
> it creates temp tables in shm_mem with the results
>
> if implements fetch_result so that startup procedures that fetch all
> rows can safely run without memory issues.
>
>
> if anyone has anything against, please reply.
>
> i would like to get this merged before 5.0
>
>
> Thanks
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20170106/e9606e39/attachment.html>


More information about the sr-dev mailing list