Запуск нескольких процессов не масштабируется
Существует два процесса C++, по одному потоку в каждом процессе. Поток обрабатывает сетевой трафик (Diameter) от 32 входящих TCP-соединений, анализирует его и пересылает разделенные сообщения через 32 исходящих TCP-соединения. Давайте назовем этот процесс C++ DiameterFE.
Если запущен только один процесс DiameterFE, он может обрабатывать 70 000 сообщений в секунду.
Если запущены два процесса DiameterFE, они могут обрабатывать 35 000 сообщений в секунду каждый, то есть в общей сложности те же 70 000 сообщений в секунду.
Почему они не масштабируются? Что такое узкое место?
Подробно: для каждого процесса Diameter-интерфейса, работающего на отдельных хостах, имеется 32 клиента (чайка) и 32 сервера (чайка).
Для этих двух процессов выделен выделенный хост - 2 процессора E5-2670 с частотой 2,60 ГГц, 8 ядер / сокет, 2 потока HW / ядро = всего 32 потока.
Сеть 10 Гбит / с. Средний диаметр сообщения составляет 700 байт.
Похоже, что только Cpu0 обрабатывает сетевой трафик - 58,7%. Нужно ли явно настраивать разные сетевые очереди для разных процессоров?
Первый процесс (PID=7615) занимает 89,0% ЦП, он работает на Cpu0.
Второй процесс (PID=59349) занимает 70,8 % ЦП, он работает на Cpu8.
С другой стороны, Cpu0 загружается при: 95,2% = 9,7%us + 26,8%sy + 58,7%si,
тогда как Cpu8 загружается только при 70,3% = 14,8 % сша + 55,5% си
Похоже, что Cpu0 выполняет работу и для второго процесса. Здесь очень высокая мягкость и только на Cpu0 = 58,7%. Зачем?
Вот верхний вывод с нажатой клавишей "1":
top - 15:31:55 up 3 days, 9:28, 5 users, load average: 0.08, 0.20, 0.47
Tasks: 973 total, 3 running, 970 sleeping, 0 stopped, 0 zombie
Cpu0 : 9.7%us, 26.8%sy, 0.0%ni, 4.8%id, 0.0%wa, 0.0%hi, 58.7%si, 0.0%st
...
Cpu8 : 14.8%us, 55.5%sy, 0.0%ni, 29.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
...
Cpu31 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 396762772k total, 5471576k used, 391291196k free, 354920k buffers
Swap: 1048568k total, 0k used, 1048568k free, 2164532k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7615 test1 20 0 18720 2120 1388 R 89.0 0.0 52:35.76 diameterfe
59349 test1 20 0 18712 2112 1388 R 70.8 0.0 121:02.37 diameterfe
610 root 20 0 36080 1364 1112 S 2.6 0.0 126:45.58 plymouthd
3064 root 20 0 10960 788 432 S 0.3 0.0 2:13.35 irqbalance
16891 root 20 0 15700 2076 1004 R 0.3 0.0 0:01.09 top
1 root 20 0 19364 1540 1232 S 0.0 0.0 0:05.20 init
...
1 ответ
Исправление этой проблемы состояло в обновлении ядра до 2.6.32-431.20.3.el6.x86_64 .
После этого сетевые прерывания и очереди сообщений распределяются между разными процессорами.