Почему время обслуживания softirqs увеличено в ядре 4.1 по сравнению с ядром 3.4?
Мы обнаружили проблему снижения производительности при выполнении поднятия Linux с версии 3.4 до версии 4.1. Кажется, это связано с тем, что новое ядро тратит гораздо больше времени на обслуживание softirqs.
Мы провели тест с использованием генератора трафика (IXIA), который генерирует пакеты GTP-C (по UDP), и простого приложения, которое отправляет полученный пакет обратно. Он просто меняет IP-адреса источника и назначения. С помощью утилиты mpstat мы получили следующие результаты:
- ядро 3.4
# mpstat -P ALL 60 1 Linux 3.4.91-grsec (...) 22.12.17 _x86_64_ (20 CPU) 15:58:43 CPU %usr %nice %sys %iowait %irq %soft %steal %guest % простаивает 15:58:53 все 0,26 0,00 2,21 0,00 0,00 0,41 0,00 0,00 97,12 15:58:53 0 1,03 0,00 3,79 0,00 0,00 12,91 0,00 0,00 82,27 15:58:53 1 4,18 0,00 41,44 0,00 0,00 0,00 0,00 0,00 0,00 54,38 15:58: 53 2 0,30 0,00 0,30 0,00 0,00 0,40 0,00 0,00 99,00 ... # mpstat -I ALL -P 0 60 1 Linux 3,4,91-grsec (...) 25/25/17 _x86_64_ (20 ЦП) 10:53:16 CPU intr / s 10:54:16 0 0.00 10:53:16 CPU 0 / s 3 / s 4 / s 8 / s 9 / s 67 / s 68 / s 69 / s 70 / s 71 / s 72 / с 73 / с 74 / с 75 / с 76 / с 77 / с 78 / с 79 / с 80 / с 81 / с 82 / с 83 / с 84 / с 103 / с 104 / с 105 / с 106 / с 106 / с 107 / с 108 / с 109 / с 110 / с 111 / с 112 / с 113 / с 114 / с 115 / с 116 / с 117 / с 118 / с 118 / с 119 / с 120 / с 121 / с 122 / с 123 / с 124 / с 125 / с 126 / с 127 / с 128 / с 129 / с 130 / с 130 / с 131 / с 132 / с 133 / с 134 / с 135 / с 136 / с 137 / с 138 / с 139 / с 140 / с 141 / с 142 / с 143 / с 144 / с NMI/ с LOC/ с SPU/ с PMI/ с IWI/ с RTR/ с RES/ с CAL/ с TLB/ с TRM/ с THR/ с MCE/s MCP/ с ERR/ с MIS/s 10:54:16 0 0,00 5,50 0,00 0,00 0,00 0,00 71. 59 0,50 1,60 6,47 1,50 16,66 0,50 1,50 0,00 71,59 0,50 0,60 6,47 1,50 16,66 1,50 1,50 126,91 17445,01 9,93 1,87 1,28 1,25 1,27 4,82 0,83 1,37 1,58 7,45 14,38 3,45 18060,49 2,18 0,97 1,00 0,58 0,83 0,00 87,70 17503,72 7,62 1,22 0,75 0,67 0,98 2,98 0,53 1,87 1,58 1,50 6,62 18028,71 1,53 0,53 0,50 0,50 0,50 0,50 0,00 0,40 174,64 0,00 0,40 0,00 0,00 282,10 0,00 0,92 0,00 0,00 0,00 0,00 0,00 0,00 0,0053: 1616 HI / s CPU ТАЙМЕР / с NET_TX/s NET_RX/s BLOCK/s BLOCK_IOPOLL/s TASKLET/ с SCHED/ с HRTIMER/ с RCU/ с 10:54:16 0 0,00 166,49 0,25 62813,75 0,00 0,00 0,00 298,20 0,87 130,00...
- ядро 4.1
# mpstat -P ALL 60 1 Linux 4.1.21 (...) 22.12.17 _x86_64_ (20 CPU) 16:19:12 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 16:19:22 все 0,28 0,00 2,23 0,00 0,00 2,65 0,00 0,00 94,84 16:19:22 0 1,40 0,00 2,59 0,00 0,00 52,79 0,00 0,00 43,21 16:19:22 1 3,66 0,00 42,47 0,00 0,00 0,00 0,00 0,00 53,87 16:19:22 2 0,10 0,00 0,20 0,00 0,00 0,00 0,00 0,00 99,70 ... # mpstat -I ALL -P 0 60 1 Linux 4.1.21 (...) 25/25/17 _x86_64_ (20 CPU) 10:35:45 CPU intr/ с 10:36:45 0 0,00 10:35:45 ЦП 0 / с 3 / с 4 / с 8 / с 9 / с 31 / с 32 / с 33 / с 34 / с 35 / с 36 / с 37 / с 38 / с 39 / с 41 / с 42 / с 43 / с 44 / с 45 / с 46 / с 47 / с 48 / с 49 / с 69 / с 70 / с 71 / с 72 / с 73 / с 74 / с 75 / с 76 / с 77 / с 78 / с 79 / с 80 / с 81 / с 82 / с 83 / с 84 / с 85 / с 86 / с 86 / с 87 / с 88 / с 89 / с 91 / с 92 / с 93 / с 94 / с 95 / с 96 / с 97 / с 98 / с 99 / с 100 / с 101 / с 102 / с 103 / с 103 / с 104 / с 105 / с 106 / с 107 / с 107 / с 108 / с 109 / с 110 / с 111 / с NMI/ с LOC/ с SPU/ с PMI/ с IWI/ с RTR/ с RES/ с CAL/ с TLB/ с TRM/ с THR/ с MCE / с MCP/s ERR/ с MIS/s 10:36:45 0 0,00 5,43 0,00 0,00 0,00 0,00 81,55 0,50 0,50 2,50 0,50 12,63 0,50 2,00 0,0 0 81,55 0,50 0,60 2,50 0,50 12,63 0,50 1,50 134,87 16949,32 3,25 2,62 3,55 1,32 17720,62 7,03 7,35 3,58 1,63 6,73 3,53 4,48 5,33 1,37 1,42 0,83 10,58 0,52 0,00 90,33 16160,05 3,72 2,07 0,73 0,82 2,53 17669,83 7,23 2,17 1,50 0,50 1,57 0,50 0,50 0,50 0,50 0,50 10,50 0,50 0,00 0,05 1005,90 0,00 0,05 0,00 0,00 4,05 1,85 0,00 0,00 0,00 0,02 0,00 0,00 10:35:45 HI / с CPU ТАЙМЕР / с NET_TX / с NET_RX / с BLOCK / с BLOCK_IOPOLL / с ЗАДАЧА / с SCHED/ с HRTIMER/ с RCU 10:36:45 0 0,00 1000,05 2,93 56777,58 0,00 0,00 0,57 285,15 0,00 1313,05...
Условия испытаний:
- Скорость трафика: 50000 кадров в секунду
- Приложение привязано к CPU 1 с помощью команды taskset
- Все прерывания (которые связаны с интерфейсами Ethernet) связаны с CPU 0.
Как мы видим, "%soft" значительно увеличивается на CPU 0: 12,91% -> 52,79%. Однако NET_RX / s уменьшается: 62813,75 -> 56777,58.
Также мы попытались профилировать CPU 0 с помощью утилиты perf. К сожалению, никакой подсказки не найдено.
- ядро 3.4
# perf stat -C 0 -e irq: softirq_entry, irq: softirq_exit, irq: softirq_raise -a sleep 60
Статистика счетчика производительности для сна 60:
3690739 irq:softirq_entry [100,00%]
3691328 irq:softirq_exit [100,00%]
4366035 irq:softirq_raise
60,020019821 секунд прошло
# perf stat -C 0 -d -a сон 60
Статистика счетчика производительности для сна 60:
59978,442551 task-clock # 0.999 Используются процессоры [100.00%]
138638 переключатели контекста # 0,002 м / с [100,00%]
4206 миграций ЦП # 0,070 К / с [100,00%]
91404 ошибок страниц # 0,002 м / с
49824470562 циклов # 0,831 ГГц [49,34%]
32279104677 фронтальные циклы с задержкой # 64,79% незанятые циклы внешнего интерфейса [48,20%]
остановленные циклы-бэкенд
41765280058 инструкций # 0,84 insns за цикл
# 0,77 остановленных циклов на инсн [62,35%]
6939461584 ветви # 115,699 М / с [62,90%]
69255081 промахи # 1,00% всех ветвей [61,90%]
13778063320 L1-dcache-load # 229,717 М / с [63,72%]
757751494 L1-dcache-load-misses # 5.50% от всех обращений L1-dcache [63.85%]
153774796 LLC-нагрузки # 2,564 м / с [50,09%]
ООО нагружать-промахи
60,065977609 секунд прошедшего времени- ядро 4.1
# perf stat -C 0 -e irq: softirq_entry, irq: softirq_exit, irq: softirq_raise -a sleep 60 Статистика счетчика производительности для 'CPU(s) 0':
3540101 irq:softirq_entry (100,00%)
3540380 irq:softirq_exit (100,00%)
4365512 irq:softirq_raise
60.061923392 секунд прошедшего времени # perf stat -C 0 -d -a sleep 60 Статистика счетчика производительности для 'CPU(s) 0':
60105.618981 task-clock (msec) # 1.001 Используемые CPU (100.00%) контекст 112358 -переключатели # 0,002 М / с (100,00%)
3042 миграций ЦП # 0,051 К / с (100,00%)
23077 сбоев страниц # 0,384 К / с 69596616908 циклов # 1,158 ГГц (44,44%)
47063269010 фронт-циклы с остановленными циклами # 67,62 % фронтов циклов простоя (44,43%)
stalled-cles-backend
47882140206 инструкции # 0,69 insns за цикл # 0,98 остановленных циклов на Insn (55,54%)
8644786229 веток # 143,827 М / с (55,54%)
82066359 пропусков ветвей # 0,95% от всех разветвления (55,55%)
15150062571 L1-dcache-load # 252,057 М / с (44,45%)
891694267 L1-dcache-load-misses # 5,89% всех обращений L1-dcache (22,23%)
192155955 LLC-загрузки # 3,197 M/sec (22,23%)
148469 LLC-load-misses # 0,08% от всех обращений LL-кэша (33,33%) 60.062744860 секунд прошлоМожет быть, кто-то сталкивался с подобной проблемой. Любые советы и предложения будут с благодарностью.
2 ответа
Подобная проблема возникала при обновлении ядра с 3.16 до 4.9 (например, с Debian Jessie на Debian Stretch).
Производительность сети по UDP значительно упала.
У нас не было вспышки гения, которая помогла нам найти виновника для этого.
Тем не менее, мы сделали некоторые настройки и подошли довольно близко к предыдущему результату:
1) Использование RSS. Статически назначьте ядра ЦП очередям приема сетевых карт. Остановите службу irqbalance. RPS и RFS не улучшили производительность по сравнению с тем, что RSS сделала в нашем случае, но это может быть полезно для вас, в зависимости от вашего оборудования.
2) Уменьшите интервал, через который планировщик становится активным. Я просто использовал параметры из этой статьи.
Возможно, причина заключается в смягчении уязвимостей, связанных с призраками и распадами. Попробуйте передать "nospectrev2 nopti nopcid" в качестве параметров загрузки для вашего ядра. Имейте в виду, что эти изменения являются потенциальной дырой в безопасности.