Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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.