It seems I met a interest issue raised by LUKE
[CRIT] switch_core_session.c:1861 Thread Failure!
[CRIT] switch_core_session.c:1817 LUKE: I’m hit, but not bad.
[CRIT] switch_core_session.c:1818 LUKE’S VOICE: Artoo, see what you can do with it. Hang on back there…
Green laserfire moves past the beeping little robot as his head turns. After a few beeps and a twist of his mechanical arm,
Artoo reduces the max sessions to 4051 thus, saving the switch from certain doom.
I’m wondering how it could be?
In what stuation it will be trigger?
This issue could be reproduced on certain host(36core, CentOS7) during sipp test, whenever peak calls nearly reach 4000, it takes place.
On another(20core, CentOS7) host, it never appear, although there are totally using equal fs release and config.
runtime command echo is here
CentOS
cat /proc/cpuinfo |grep processor|wc -l
72
cat /proc/sys/kernel/threads-max
1029374
ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 514687
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1048567
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 65535
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited