У меня есть сценарий, который я пишу, который запускает плохие блоки на дисковой полке, заполненной дисками, и я пытаюсь понять, какая нагрузка на сервер увеличивается и в какой момент нагрузка на сервер критична в этом сценарии использования.
Я обычно придерживался общего правила, согласно которому нагрузка на сервер <= # of_cores является идеальной, тогда как <= 2x #of_cores, как правило, не вызовет значительного снижения производительности, если не обслуживает рабочие нагрузки, чувствительные в реальном времени, но я не думаю, что это применимо в этом случае использования.
На приведенном ниже снимке экрана сверху вы видите, что я использую плохие блоки для 8 устройств, связанная нагрузка составляет ~ 8, что я понимаю, поскольку 8 процессов эффективно остановились в очереди из-за природы плохих блоков. Но только 2 ядра процессора связаны этими процессами. Итак, пара вопросов:
1.> Замедляю ли я тестирование плохого блока, пытаясь выполнить такое количество одновременных тестов, и если да, то почему он не использует доступные ядра?
2.> Я предполагаю, что эта в целом «неидеальная» загрузка процессора не повлияет на обслуживание других запросов, например, на данные, совместно используемые с других дисков на сервере? (при условии отсутствия узких мест на карте sas), потому что 2 ядра свободны и доступны правильно?
3.> Если 2 ядра могут поддерживать 8 процессов плохой блокировки без влияния друг на друга (как показано), иначе почему два процесса плохой блокировки используют одно ядро, а третье вызывает использование второго ядра, то планирование / оптимизация будет означать один предположить, что 8 процессов должны потреблять 3-4 ядра, а не 2 оптимально запланированных нет?
Платформа - Centos 7 | - | Процессор Intel e3-1220 v2 (четырехъядерный без гиперпоточности) | - | Дисковая полка подключается к серверу через внешний SAS HBA (без рейда)
top - 16:03:12 up 6 days, 15:21, 13 users, load average: 7.84, 7.52, 6.67
Tasks: 171 total, 2 running, 169 sleeping, 0 stopped, 0 zombie
%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 99.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 0.3 us, 6.0 sy, 0.0 ni, 0.0 id, 93.6 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni, 95.7 id, 4.3 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 2.3 us, 3.0 sy, 0.0 ni, 0.0 id, 94.7 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 7978820 total, 7516404 free, 252320 used, 210096 buff/cache
KiB Swap: 4194300 total, 4194300 free, 0 used. 7459724 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22322 root 20 0 122700 9164 832 D 3.3 0.1 18:36.77 badblocks
22394 root 20 0 122700 9164 832 D 1.3 0.1 15:52.98 badblocks
23165 root 20 0 122700 9152 820 D 1.3 0.1 0:36.94 badblocks
23186 root 20 0 122700 5792 808 D 1.3 0.1 0:02.54 badblocks
23193 root 20 0 122700 5004 768 D 1.3 0.1 0:02.17 badblocks
23166 root 20 0 122700 9152 820 D 1.0 0.1 0:36.11 badblocks
23167 root 20 0 122700 9148 820 D 1.0 0.1 0:39.74 badblocks
23194 root 20 0 122700 6584 808 D 1.0 0.1 0:01.47 badblocks
Средняя нагрузка - это медленно изменяющийся показатель, приблизительно равный количеству выполняемых задач на ЦП. Кроме, На раннем этапе Linux решил также учитывать непрерывные задачи в надежде поймать нагрузку ввода-вывода. Нагрузка ниже количества процессоров определенно может выполнять больше задач, но рекомендуемый максимум не так очевиден.
Дисковый ввод-вывод в современных системах требует минимального использования ЦП. Итак, iowait почти простаивает. Такой низкий уровень системы User + указывает на то, что ЦП мало чем занимается в ожидании очень медленных шпинделей.
Не более одного плохого блока на физический шпиндель. Несколько устройств могут перемещаться по головке диска вперед и назад, что приведет к ужасной производительности.
Возможно, есть также узкое место в карте SAS или другом компоненте системы хранения. Когда вы видите пропускную способность ввода-вывода (возможно, через iotop) больше не увеличиваются, используйте меньше процессов. Или просто выберите 8 или около того за раз в качестве партии произвольного размера для параллельной работы (возможно, с GNU parallel).
Планировщик задач оптимизируется для нескольких вещей. Даже в системе с несколькими процессорами сосредоточение внимания на нескольких ядрах может поддерживать данные в кэше в горячем состоянии, ограничивать количество бездействующих ядер для экономии энергии и при этом иметь возможность обрабатывать прерывания. Кроме того, следует учитывать особенности планирования NUMA и SMT, хотя этот ЦП не имеет этих функций.
В данном случае у вас два практически незанятых ядра. Я ожидал, что хозяин будет достаточно живым. Хотя, пока вы это делаете, не выполняйте больше работы. Ограниченная пропускная способность ввода-вывода и количество операций ввода-вывода в секунду могут привести к тому, что процессоры будут ждать, пока объем выполненной работы не увеличивается.