iowait Bound Server - Расчет нагрузки и планирование процессов
У меня есть сценарий, который я пишу, который запускает плохие блоки на дисковой полке, заполненной дисками, и я пытаюсь понять, насколько увеличивается нагрузка на сервер и в какой момент нагрузка на сервер критична в этом случае.
Я обычно придерживался общего правила, согласно которому нагрузка на сервер <= # of_cores является идеальной, в то время как <= 2x #of_cores, как правило, не вызовет значительного снижения производительности, если только обслуживание не выполняется в реальном времени чувствительных рабочих нагрузок, но я не думаю, что в данном случае можно применить универсальность.
На приведенном ниже снимке экрана из t Как вы видите, я использую плохие блоки для 8 устройств, соответствующая нагрузка составляет ~ 8, что я понимаю, поскольку из-за природы плохих блоков в очереди эффективно останавливаются 8 процессов. Но только 2 ядра процессора связаны этими процессами. Итак, пара вопросов:
1.> Замедляю ли я тестирование плохого блока, пытаясь выполнить такое количество одновременных тестов, и если да, то почему он не использует доступные ядра?
2.> Обычно я так предполагаю " неидеальная "загрузка процессора не повлияет на обслуживание других запросов, например, данных, совместно используемых с других дисков на сервере?" (при условии отсутствия узких мест на карте sas), потому что 2 ядра свободны и доступны правильно?
3.> Если 2 ядра могут поддерживать 8 процессов плохих блоков без влияния друг на друга (как показано), другое, почему это 2 плохих блока процессы используют одно ядро, в то время как третье задействует второе ядро, это планирование / оптимизация подразумевает предположение, что 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 + system» указывает на то, что ЦП мало чем занят в ожидании очень медленных шпинделей.
Параллельные задания для этой рабочей нагрузки
Ограничение до одного плохого блока на физический шпиндель. Несколько может перемещаться по головке диска вперед и назад, что приведет к ужасной производительности.
Возможно, также существует узкое место в карте SAS или другом компоненте системы хранения. Когда вы видите, что полоса пропускания ввода-вывода (возможно, через iotop ) больше не увеличивается, используйте меньше процессов. Или просто выберите 8 или около того за раз в качестве пакета произвольного размера для параллельной работы (возможно, с GNU parallel ).
Планирование задач
Планировщик задач оптимизирует несколько вещей. Даже в многопроцессорной системесосредоточение внимания на нескольких ядрах может поддерживать данные в кэше в горячем состоянии, ограничивать количество бездействующих ядер для экономии энергии и при этом иметь возможность обрабатывать прерывания. Кроме того, необходимо учитывать планирование NUMA и SMT, хотя этот ЦП не имеет этих функций.
В этом случае у вас есть два почти незанятых ядра. Я ожидал, что хозяин будет достаточно живым. Хотя, пока вы это делаете, не выполняйте больше работы. Ограниченная пропускная способность ввода-вывода и количество операций ввода-вывода в секунду могут привести к тому, что процессоры будут ждать, пока объем выполненной работы не увеличивается.