Уже была аналогичная тема про Solaris/SPARC
https://olegon.ru/showthread.php?t=30938
Теперь столкнулись с тем, что на Power9 архиватор работал с 12% до 21% столько, что я успел включить свой старенький x86, сделать файлик такого же размера и сжать его с 0% до 100%. Возник вопрос, поскольку на этом Power9 работает самая крупная база, с которой я вообще имел дело.
Соответственно, следуя правилам упрощения testcase, я сделал простенький тест
Код:
time dd if=/dev/urandom of=/u01/test count=1024 bs=1M
1024+0 records in.
1024+0 records out.
real 1m10.376s
user 0m0.012s
sys 0m16.895s
time gzip -9 test
real 1m31.729s
user 0m13.693s
sys 0m4.200s
это однопоточная генерация файлика с произвольными числами и сжатие его максимальной компрессией. И тут мой старенький десктоп порвал Power9, как тузик грелку (10 секунд против 1m10s). Однако, обращаю внимание, что real и user в этом самом Power9 очень сильно различаются.
Получил контраргумент
Цитата: Изучил матчасть: отличие elapsed и CPU - это результат нормирования на уровне железа Power
1 поток грузит на 34%, 1/3
2 потока грузят на 58%, значит каждый на 29%
4 потока грузят на 80%, каждый на 20% - отсюда соотношение 1/5 днем в пик.
8 на 100%, каждый на 12.5, 1/8.
и
Цитата: Power считает CPU двумя способами, для этого есть 2 группы регистров:
- как астрономическое время (wall clock) работы процесса в процессоре
- как нормированное время описанным выше способом.
Последнее динамически учитывает степень многопоточности в процессе работы. Его суть в том, что при полной загрузке CPU (8 потоков) сумма всех потоков даст 100%. Разными командами UNIX можно получить оба этих значения "процессорного" времени. Насколько я понял (и это соответствует экспериментальным данным), AIX подсовывает в Oracle второе, нормированное значение CPU. Поэтому при измерении для одного процесса (потока) мы получаем кратный "дефицит" CPU, в зависимости от средней многопоточности (m) за период измерений, а в сумме при полной загрузке системы - 100% * число ядер.
Это же значение использует nmon.
Результаты сравнения P9 с x86 дают следующее: в однопоточном режиме x86 работает в 3 раза быстрее p9, максимальная производительность p9 (в 8-поточном она в 3 раза выше) примерно равна x86.
В 2-поточном x86 вероятно обгонит p9 на 30-50%.
Я представляю картину немного не так.
У потока самого по себе вычислительной мощности никакой. Это просто конвеер, который подает рабочему детали для обработки (вспомнился Чаплин в "Новые времена"). Считает ядро. Это не какой-то фантастический сверхразум, а просто железка, которая линейно выполняет инструкции одну за другой. В силу задержек памяти и т.п. детали подаются рабочему с интервалом, уменьшить который нельзя физически. У нас ядер 120, а потоков 960 (SMT8).
Чтобы нагрузить процессор сильнее, рабочему добавили еще 7 конвееров, чтобы пока до него по одному конвееру едет деталь, он мог обработать деталь на другом конвеере. И это действительно ускоряет процессы, но только до того момента, пока вычисления не становятся достаточно тяжелыми, чтобы затраты на выполнение инструкции стали по времени дольше, чем интервал между деталями. Минусом имеем накладные расходы, поскольку комплекс из конвееров надо тоже обслуживать (рабочий должен протянуть руки к другому конвееру).
У нашего рабочего сейчас 8 конвееров, поскольку на сервере SMT8. То есть, при нагрузке 100% потоков, нагрузка процессора может быть до 800%. Подчеркну, что "до", а не обязательно ровно 800%. Соответственно, после 100% начинается деградация, ядро не может считать быстрее своих физических возможностей только потому, что ему больше подбрасывают. И, чем плотнее потоки для расчета, чем сильнее нагружены ядра, тем явнее эта деградация проявляется. Именно поэтому я всегда настоятельно рекомендую отключать многопоточность и прочие маркетинговые Hyperthreading на тех серверах, где активных потоков на CPU больше реальных ядер. Для веб-сервера или офисных машин потоки - благо, поскольку есть отвлекающие от CPU факторы, вроде передачи по сети. Для сильно нагруженного сервера СУБД - потоки зло. Особенно тем зло, что cpu_count в итоге видит потоки и, являясь производным для многих других параметров, готовит сервер считать нормальной нагрузку, которую он физически не выдержит.
Говорить о том, что x86 в 3 раза быстрее p9, я бы тоже не стал. Скорее, p9 в 3 раза медленнее, чем x86, что при среднем ускорении в 10%, которое сейчас наблюдается между поколениями процессоров, дает нам картину работы на сервере, выпущенном больше 10 поколений назад. На самом же деле это тоже усредненное между неизвестными. CPUSPEEDNW (метрика однопоточной производительности Oracle) - 4194 на x86 и 2183 на Power9, то есть разница менее, чем в 2 раза. Это синтетика на одном ядре до запуска базы. Замедление в 3 раза - это эффект размазывания общей нагрузки по ядрам. Именно поэтому 8-поточное выполнение (а размазать большинство операций CPU по 8 потокам просто не удастся) будет при SMT8 догонять x86 только до тех пор, пока все ядра не будут заняты, то есть до 12.5% (1/8) нагрузки. Именно поэтому архивирование (тяжелое вычисление), выполняется с 10-кратным замедлением. Возможно, что и в базе легкие операции (пустые циклы, например) при отсутствии тяжелых операций выполняются с небольшим замедлением, а тяжелые скопом - до 10 раз медленее. Достаточно изменить профиль нагрузки на более тяжелые вычисления с тем же количеством сессий, как сервер начнет работать в 10 раз медленее.