Существует ли разумный / безопасный уровень загрузки ЦП в контексте высокопроизводительных вычислений?
Я понимаю смысл из средняя нагрузка для серверов в целом, но не знаю, чего ожидать от серверов, построенных и используемых для высокопроизводительных вычислений.
Обычное соглашение load <= # of cores применимо в этой среде?
Мне любопытно, учитывая особенности моей системы, где обычно load >> # of cores для каждого узла:
Узлы имеют высокое время безотказной работы с обычно высокой загрузкой / загрузкой ЦП. Аппаратных сбоев очень мало, особенно для ЦП, но я не знаю, чего ожидать в течение срока службы узлов при высокой нагрузке.
пример top вывод:
top - 14:12:53 up 4 days, 5:45, 1 user, load average: 313.33, 418.36, 522.87
Tasks: 501 total, 5 running, 496 sleeping, 0 stopped, 0 zombie
%Cpu(s): 33.5 us, 50.9 sy, 0.0 ni, 15.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 19650371+total, 46456320 free, 43582952 used, 10646443+buff/cache
KiB Swap: 13421772+total, 78065520 free, 56152200 used. 15164291+avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
85642 user 20 0 36.5g 7.6g 245376 S 1566 4.0 1063:21 python
97440 user 20 0 33.1g 5.3g 47460 S 1105 2.8 512:10.86 python
97297 user 20 0 31.0g 4.0g 69828 S 986.4 2.1 430:16.32 python
181854 user 20 0 19.3g 5.0g 19944 R 100.0 2.7 2823:09 python
...
Выход iostat -x 5 3 на том же сервере:
avg-cpu: %user %nice %system %iowait %steal %idle
50.48 0.00 12.06 0.38 0.00 37.08
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 350.41 705.68 58.12 22.24 2126.25 3393.61 137.36 6.02 74.93 9.10 246.94 1.19 9.56
dm-0 0.00 0.00 4.87 8.70 511.41 516.65 151.59 0.31 22.55 28.40 19.28 2.62 3.56
dm-1 0.00 0.00 403.67 719.23 1614.71 2876.92 8.00 8.83 7.10 7.38 6.95 0.08 9.05
dm-2 0.00 0.00 0.00 0.00 0.02 0.01 65.03 0.00 3.74 3.82 1.00 2.12 0.00
Средняя загрузка показывает очередь потоков, готовых к запуску. В Linux это также включает потоки, ожидающие диска. Может случиться так, что сломанный сервер NFS может увеличить среднюю нагрузку до безумных цифр. Это не означает, что процессоры перегружены.
Таким образом, средняя загрузка показывает только одну сторону истории, и ее нельзя рассматривать в одиночку, поэтому я просил top вывод.
Некоторые рабочие нагрузки нельзя распараллеливать. Это означает, что все шаги будут выполняться на одном и том же ядре один за другим. Реальные задачи обычно частично распараллеливаются.
В исполнении у вас есть некоторые цели и ограничения. Например, низкая задержка, пропускная способность, стоимость (начальная стоимость и эксплуатационные) ...
Если вас интересует пропускная способность и низкая стоимость, наличие большой очереди может быть нормальным. Все ядра вашего ЦП будут постоянно загружены на 100%.
Средняя нагрузка - это всего лишь симптом, полезный показатель, который операционная система может сообщить. Врач не может диагностировать, что не так с пациентом-человеком только с симптомом лихорадки, у него гораздо больше вопросов о том, что происходит. Точно так же, как и в случае с компьютерными пациентами, требуется гораздо больше информации о том, как они работают.
Средняя загрузка может незначительно отличаться между системами. Некоторые платформы не сообщают о задачах, которые, вероятно, выполняют ввод-вывод при средней нагрузке, что отличается от того, как это делает Linux. Некоторые хосты могут иметь среднюю нагрузку на ядро в несколько десятков и не падать. Некоторые приложения очень чувствительны к задержкам, и нагрузка на ядро больше единицы видна из-за плохого времени отклика пользователя.
Помимо метрик на уровне ОС, собирайте тесты производительности для конкретных приложений и отслеживайте их динамику. Общие примеры:
Чтобы получить некоторую оценку полезной работы, которую выполняет система, необходимо поместить метрики ОС в контекст. Кажется, ваша система выполняет полезную работу даже при относительно высокой средней нагрузке. В отличие от вилочной бомбы, которая доводит нагрузку до неприемлемо высокого уровня, но как отказ в обслуживании не делает ничего полезного.