hello all

we have seen some cores on the same server like this one

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f02297a0537 in __GI_abort () at abort.c:79
#2  0x000055caeb47dc3d in qm_debug_check_frag (qm=0x7f00aba53000, f=0x7f019c02c760, file=0x7f0222d42d32 "dialog: dlg_hash.c", line=412, efile=0x55caeb60c079 "core/mem/q_malloc.c", eline=511) at core/mem/q_malloc.c:158
#3  0x000055caeb48148a in qm_free (qmp=0x7f00aba53000, p=0x7f019c02c798, file=0x7f0222d42d32 "dialog: dlg_hash.c", func=0x7f0222d43338 <__func__.17> "destroy_dlg", line=412, mname=0x7f0222d42d2b "dialog")
    at core/mem/q_malloc.c:511
#4  0x000055caeb48c6a9 in qm_shm_free (qmp=0x7f00aba53000, p=0x7f019c02c798, file=0x7f0222d42d32 "dialog: dlg_hash.c", func=0x7f0222d43338 <__func__.17> "destroy_dlg", line=412, mname=0x7f0222d42d2b "dialog")
    at core/mem/q_malloc.c:1276
#5  0x00007f0222cf9bb8 in destroy_dlg (dlg=0x7f00cdec7d28) at dlg_hash.c:412
#6  0x00007f0222d03b8b in dlg_unref_helper (dlg=0x7f00cdec7d28, cnt=2, fname=0x7f0222d3ea61 "dlg_handlers.c", fline=431) at dlg_hash.c:1095
#7  0x00007f0222ce1146 in dlg_ontdestroy (t=0x7f01f1b17808, type=131072, param=0x7ffe98532bd0) at dlg_handlers.c:431
#8  0x00007f0225607741 in run_trans_callbacks_internal (cb_lst=0x7f01f1b17880, type=131072, trans=0x7f01f1b17808, params=0x7ffe98532bd0) at t_hooks.c:258
#9  0x00007f0225607871 in run_trans_callbacks (type=131072, trans=0x7f01f1b17808, req=0x0, rpl=0x0, code=0) at t_hooks.c:285
#10 0x00007f02255b179c in free_cell_helper (dead_cell=0x7f01f1b17808, silent=0, fname=0x7f02256c2d72 "timer.c", fline=648) at h_table.c:165
#11 0x00007f022560e036 in wait_handler (ti=1916150547, wait_tl=0x7f01f1b17890, data=0x7f01f1b17808) at timer.c:648
#12 0x000055caeb44121a in timer_list_expire (t=1916150547, h=0x7f00abad2360, slow_l=0x7f00abad6278, slow_mark=34766) at core/timer.c:857
#13 0x000055caeb441724 in timer_handler () at core/timer.c:922
#14 0x000055caeb441c27 in timer_main () at core/timer.c:961
#15 0x000055caeb1896cf in main_loop () at main.c:1839
#16 0x000055caeb1942e9 in main (argc=15, argv=0x7ffe98533618) at main.c:3061

in this server we are having very high call rate, more than 2000 calls per second.

this is the dialog module setup we have

modparam("dialog", "db_url", DBURL_DIALOG)
modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 16384)
modparam("dialog", "dlg_flag", 31)
modparam("dialog", "default_timeout", 14500)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "db_mode", 0)
modparam("dialog", "profiles_with_value", "dedalus")
modparam("dialog", "timer_procs", 1)
modparam("dialog", "db_skip_load", 1)
modparam("dialog", "db_update_period", 60)
modparam("dialog", "db_fetch_rows", 1000)

changing to this

modparam("dialog", "db_url", DBURL_DIALOG)
modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 32768)
modparam("dialog", "dlg_flag", 31)
modparam("dialog", "default_timeout", 14500)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "db_mode", 0)
modparam("dialog", "profiles_with_value", "dedalus_in ; dedalus_out")
modparam("dialog", "timer_procs", 1)
modparam("dialog", "db_skip_load", 1)
modparam("dialog", "db_update_period", 60)
modparam("dialog", "db_fetch_rows", 1000)
modparam("dialog", "wait_ack", 0)

AS far as i understand, cores are related to dialog end handling ?¿
increasing hash_size and setting wait_ack to 0 woudl help to the performance?

thanks a lot and regards
david


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <kamailio/kamailio/issues/3593/1783367555@github.com>