aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/test/diameter_3xxx_SUITE.erl
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2015-07-18 14:04:28 +0200
committerAnders Svensson <[email protected]>2015-07-19 11:08:21 +0200
commit4f365c072b6df771004b388dd7e66f08e37ac5e7 (patch)
treec3fe3f7437c0a91c1ee4126aaf4608507ee39835 /lib/diameter/test/diameter_3xxx_SUITE.erl
parent862af31d8a91b56711e3da554bb08247b7ee43cd (diff)
downloadotp-4f365c072b6df771004b388dd7e66f08e37ac5e7.tar.gz
otp-4f365c072b6df771004b388dd7e66f08e37ac5e7.tar.bz2
otp-4f365c072b6df771004b388dd7e66f08e37ac5e7.zip
Don't start watchdog timers unnecessarily
In particular, restart the timer with each incoming Diameter message, only when the previous timer has expired. Doing so has been seen to result in high lock contention at load, as in the example below: (diameter@test)9> lcnt:conflicts([{print, [name, tries, ratio, time]}]). lock #tries collisions [%] time [us] ----- ------- --------------- ---------- bif_timers 7844528 99.4729 1394434884 db_tab 17240988 1.7947 6286664 timeofday 7358692 5.6729 1399624 proc_link 4814938 2.2736 482985 drv_ev_state 2324012 0.5951 98920 run_queue 21768213 0.2091 63516 pollset 1190174 1.7170 42499 pix_lock 1956 2.5562 39770 make_ref 4697067 0.3669 20211 proc_msgq 9475944 0.0295 5200 timer_wheel 5325966 0.0568 2654 proc_main 10005332 2.8190 1079 pollset_rm_list 59768 1.7752 480
Diffstat (limited to 'lib/diameter/test/diameter_3xxx_SUITE.erl')
0 files changed, 0 insertions, 0 deletions