Hello,
I am opening this discussion to decide if there is need to adjust some of the default values we have in Kamailio. Many of them were set even like 10 years ago, so they might not be very actual anymore.
The main goal is to get the best possible settings for common usage.
To start with, here are some values that should be reviewed:
- default private memory is 4MB - if the config is not that small, it might not be sufficient free pkg to play with (e.g., for sql_query() result, storage of $var(...) values). Should it be increased to 8MB or other value? Debian/Centos have startup script that sets its value to 8 via command line
- default shared memory is 32MB - for a decent deployment with tm, location, lcr/dispatcher, permissions, and anti-flood, it might leave not much free space. Should we double it or set to a different value
- usrloc - db_ops_ruid should enabled (1) - seems stable, without it there are problems updating/deleting location records when UA changes the call-id for same contact address.
- usrloc - hash_size - now is 9, which results in 512 slots, meaning is ok for few thousands of registered users, for more, performance will decrease when doing save/lookup location -- should it be made 10 (1024 slots for internal hash table)?
- auth_db - load_credentials defaults to 'rpid', meaning that the query to get the password will retrieve also the rpid column. I haven't see rpid being used that much lately (replaced by PAI/PPI). I would make this parameter empty by default to avoid querying for an extra column that is likely to be empty.
Perhaps there are more, I just wanted to get started. Reply with your comments to above list as well as add new items you thinks their default values should be adjusted.
Cheers, Daniel
Daniel-Constantin Mierla writes:
- default private memory is 4MB - if the config is not that small, it
might not be sufficient free pkg to play with (e.g., for sql_query() result, storage of $var(...) values). Should it be increased to 8MB or other value? Debian/Centos have startup script that sets its value to 8 via command line
i agree on increasing this to 8 MB. my sip-proxy does not start with 4. it starts with 8 on i386, but not on amd64 arch.
- default shared memory is 32MB - for a decent deployment with tm,
location, lcr/dispatcher, permissions, and anti-flood, it might leave not much free space. Should we double it or set to a different value
my proxy is happy with 32 here.
- usrloc - db_ops_ruid should enabled (1) - seems stable, without it
there are problems updating/deleting location records when UA changes the call-id for same contact address.
i agree.
- usrloc - hash_size - now is 9, which results in 512 slots, meaning is
ok for few thousands of registered users, for more, performance will decrease when doing save/lookup location -- should it be made 10 (1024 slots for internal hash table)?
i'm fine with that change.
- auth_db - load_credentials defaults to 'rpid', meaning that the query
to get the password will retrieve also the rpid column. I haven't see rpid being used that much lately (replaced by PAI/PPI). I would make this parameter empty by default to avoid querying for an extra column that is likely to be empty.
i agree, since i have modparam("auth_db", "load_credentials", "") in my config.
-- juha
Hello,
apart of shared memory size (still to be considered), I made the other changes.
Based on last days of testing at SIPit31 and reviewing my configs, few other values look a bit small considering what we can get on the wire:
- tcp_rd_buf_size - it is 4096b, but with audio/video and ice, the size is to small. I propose either 8k or even 16k - pv_buffer_size - it is 1024b, given the above and that this is used for variables, many don't fit. The same as above, I propose 8k or 16k
Opinions, other internals that we should consider for adjusting default value?
Cheers, Daniel
On 16/04/14 12:41, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
- default private memory is 4MB - if the config is not that small, it
might not be sufficient free pkg to play with (e.g., for sql_query() result, storage of $var(...) values). Should it be increased to 8MB or other value? Debian/Centos have startup script that sets its value to 8 via command line
i agree on increasing this to 8 MB. my sip-proxy does not start with 4. it starts with 8 on i386, but not on amd64 arch.
- default shared memory is 32MB - for a decent deployment with tm,
location, lcr/dispatcher, permissions, and anti-flood, it might leave not much free space. Should we double it or set to a different value
my proxy is happy with 32 here.
- usrloc - db_ops_ruid should enabled (1) - seems stable, without it
there are problems updating/deleting location records when UA changes the call-id for same contact address.
i agree.
- usrloc - hash_size - now is 9, which results in 512 slots, meaning is
ok for few thousands of registered users, for more, performance will decrease when doing save/lookup location -- should it be made 10 (1024 slots for internal hash table)?
i'm fine with that change.
- auth_db - load_credentials defaults to 'rpid', meaning that the query
to get the password will retrieve also the rpid column. I haven't see rpid being used that much lately (replaced by PAI/PPI). I would make this parameter empty by default to avoid querying for an extra column that is likely to be empty.
i agree, since i have modparam("auth_db", "load_credentials", "") in my config.
-- juha
Daniel-Constantin Mierla writes:
- tcp_rd_buf_size - it is 4096b, but with audio/video and ice, the size
is to small. I propose either 8k or even 16k
i have used 16k in my setups.
- pv_buffer_size - it is 1024b, given the above and that this is used
for variables, many don't fit. The same as above, I propose 8k or 16k.
4k has worked for me so far.
-- juha
One more came in my mind:
- failure_reply_mode in tm set to 3 (now is 0)
Daniel
On 02/10/14 10:30, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
- tcp_rd_buf_size - it is 4096b, but with audio/video and ice, the size
is to small. I propose either 8k or even 16k
i have used 16k in my setups.
- pv_buffer_size - it is 1024b, given the above and that this is used
for variables, many don't fit. The same as above, I propose 8k or 16k.
4k has worked for me so far.
-- juha
-
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion