The 20% initialy loaded is because I load many data with MTREE, HTABLE,DIALPLAN etc....(5 million rows with MTREE..) Regarding the PKG, how do i set it? I read a few months ago that the shared and private memory on version 3.2.2 are the same. Thanks for the help :-) On 09/05/2012 11:44 AM, Uri Shacked wrote: application starts the it shows the following values: *>* shmem:fragments = 143898 *>* shmem:freesize = 3446570952 *>* shmem:max_used_size = 861854768 *>* shmem:real_used_size = 848396344 *>* shmem:total_size = 4294967296 *>* shmem:used_size = 319676976 *>* I divided the "real_used_size" with the "total_size" and notice that *>* it is 20%. So, this is my initial value of the application. *>* After 2 months with 40,000 calls per day, the relations between these *>* values is 39%. (doing a reload of the data that occupies 20% failed *>* due to "no memory") *>* So, 19% occupation of memory is normal for this amount of calls? or is *>* it a memory leak? if it is a memeory leak, how do i see where? *Hello, Too little information to go on here. A reload might fail mostly because data from the DB (e.g. with carrierroute case) is first loaded into private memory (the sql result). Depending of the module there are other tricks you could do (decrease the number of fetch rows the query returns etc.). The out of memory condition affects shared or private mem. Try to use at least 15 MB for PKG mem. If the 39% is with traffic, then it's normal, if you don't have any traffic I still would not worry. The thing that worries me a little is the value, you are using from the start around 0.8 GB of used shared memory... this is a lot. From the percentages you provided it looks ok.... Marius start kamailio it loads some data into memory. />/Now *>* calls are starting to gather up. How can I check how mach memory *>* />/does my avp's take? />/BR, />/Uri /Hello Uri, *>* *>* avp's are associated with the transactions, so they free'd when the *>* transaction stops(and calls are composed of transactions). This is true *>* for dialog information as well (dlg_var's etc.). Continuous growth in *>* memory at a constant call rate (incoming sip requests) might mean a *>* leak. If you need statistics about the total memory usage you can use *>* `kamctl fifo get_statistics all` and check for the shmem real_used_size *>* and max_used_size fields. *>* *>* Cheers, *>* Marius *>* *>* -- *>* Zbihlei Marius *>* *>* Head of *>* Linux Development Services Romania *>* * -- Zbihlei Marius Head of Linux Development Services Romania 1&1 Internet Development srl Tel KA: 754-9152 Str Mircea Eliade 18 Tel RO: +40-31-223-9152 Sect 1, Bucuresti mailto: marius.zbihlei at 1and1.ro<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users&g… 71295, Romania