Процессоры с P и E ядрами появились сравнительно недавно и как с ними уживаться все еще ломают голову разработчики.
Однако на самом деле эта дискриминация на первоклассные и второсортные ядра процессора появилась еще раньше. И пришлось изобретать свои костыли, чтобы важное запускалось на быстрых, а неважное на медленных ядрах.
Речь идет о турбо частоте. Суть в том, что практически у любого процессора базовая частота не имеет никакого значения. В режиме энергосбережения частота может быть сильно ниже базовой, а под полной загрузкой всех ядер частота также немного выше базовой (all core turbo). И конечно же, при условии отсутствия нагрузки на других, одно или несколько ядер могут повышать частоту еще выше до значения turbo.
Однако есть линейки процессоров (в частности это Xeon E5 v4), у которых определенные ядра ни при каких условиях не могут поднять частоту выше all core turbo. Будем называть их "медленными".
Все испытания провожу на домашнем роутере под ОС Debian и Xeon E5-1630v4 (4 ядра, 8 потоков, 3.7 Ггц базовая, 4.0 Ггц турбо)
apt install linux-cpupower
По-умолчанию скорей всего (если специально не менять ничего в BIOS) будут включены все C-states процессора:
watch -n0.5 "cpupower monitor -c"
В кратце: это уровни энергосбережения. Чем выше уровень, тем в более глубоком сне находится ядро и тем дольше оно из него выходит. Поэтому там где нужна больше скорость работы, а не энергосбережение, то рекомендуется держать ядра не глубже C3. А где нужна самая максимальная отзывчивость - C1, однако в этом режиме уже не будет никаких turbo частот. Поэтому ограничить на сервере до C3 - оптимальное решение, когда и хорошая отзывчивость и ядра могут повышать частоту до turbo. Помимо C-states есть также другие параметры, которыми можно смещать работу процессора либо в сторону скорости, либо в сторону экономии энергии (governor, performance bias... и все эти изменения делаются/не_делаются как в ОС, так и в BIOS - нужно рассматривать конкретный процессор и конкретную мат. плату), но здесь не об этом.
Подчеркну лишь, что в большинстве случаев по-умолчанию баланс смещен именно в сторону экономии энергии. И без ручного вмешательства процессор может не быть таким быстрым как мог бы, хотелось бы...
Проверяем теорию о медленных ядрах. Отключаем у всех ядер C1E и C3:
cpupower -c all idle-set -d2
cpupower -c all idle-set -d3
И дальше поочередно отключаем C6 у каждого из ядер, загоняя принудительно только это ядро в C1
cpupower -c 0 idle-set -d4
Видим, что ядро 0 теперь 99% времени простаивает в C1, т.е. полностью готово к работе. Хотя и работы на нем никакой не выполняется. Но главное, видим что частота его не выше 3.8 Ггц
Включаем обратно cpupower -c 0 idle-set -e4
И отключаем C6 у следующего:
cpupower -c 4 idle-set -d4
Виртуальное ядро 4 также у нас не подымается выше 3.8 Ггц
cpupower -c 1 idle-set -d4
А вот и первое ядро здорового человека, которое может подняться под 4 Ггц. Не совсем т.к. помимо этой программной настройки есть еще аппаратное управление в самом процессоре, на которое никак не повлиять. До самого максимума ядро сможет разогнаться только если на нем еще и нагрузка хоть какая-то будет.
Также мы видим, что следующее ядро 5 тоже подскочило в частоте. Т.е. виртуальные ядра 1 и 5 - это одно физическое ядро и частоты у них связаны.
cpupower -c 5 idle-set -d4
Соответственно разгоняя ядро 5, поднимается частота и у ядра 1
cpupower -c 2 idle-set -d4
cpupower -c 6 idle-set -d4
Выяснили, что ядра 2 и 6 также могут, если захотят.
cpupower -c 3 idle-set -d4
cpupower -c 7 idle-set -d4
А ядра 3/7 как и 0/4 тоже не выше 3.8 Ггц.
Итого расклад по максимальным частотам у нас получился такой:
0 - 3.8
4 - 3.8
1 - 4.0
5 - 4.0
2 - 4.0
6 - 4.0
3 - 3.8
7 - 3.8
Так в чем же проблема?
Обычно процессы запускаются на первом попавшем случайном ядре. Конечно это не доставляет неудобств в большинстве случаев и никто вообще не заморачивается такими мелочами. Особенно если задачи многопоточные и малотребовательные к CPU - типа Nginx например. Однако есть случаи, когда запускаемый процесс точно лишь однопоточный и внутренняя жаба начинает душить от осознания того что этот процесс в 50% случаев (на данном процессоре) запускается на медленных ядрах и выполняется хоть немного, но медленней чем мог бы...
На помощь приходит комманда taskset
Ею мы можем ограничивать какие конкретно ядра будут доступны для запускаемого процесса.
Для примера запакуем в 1 поток полугигабайтный каталог /usr/share на ядре 0:
и потом на ядре 1:
Отличие в 5 сек. Да, разница не такая большая как была бы с современными P и E ядрами, но она есть.
Еще примечательно, что даже подымая частоту лишь на 1 из ядер, все остальные также подтягиваются к 3.8, хоть они и находятся в C6 режиме энергосбережения. И если просто поднять частоту на всех быстрых ядрах, то итоговая максимальная частота каждого будет заметно не дотягивать до 4.0 Ггц.
Запустим архивирование в 1 поток на одном из быстрых ядер:
Видим, что при условии когда все остальные ядра находятся в покое, частота этого загруженного ядра увеличивается практически до самого верхнего потолка в 4.0 Ггц.
Загрузим все 4 быстрых ядра 4-х поточным архивированием:
Все еще хорошо конечно, однако заметно как максимальная частота каждого отдалилась от отметки 4.0 Ггц.
Ну и загрузим по максимуму все 8 ядер:
Получили all core turbo в 3.8 Ггц.
Раскрасив на графике мониторинга (collectd + rrdtool) ядра 1,5,2,6 красным, а остальные зеленым (не смотрим на подпись под графиком), наглядно видим как зеленые никогда не выходят выше, куда могут красные:
Как это использовать на практике? Каждый решит для себя. На своем к примеру, я ограничил малозначимые процессы только медленными ядрами. Ни к чему чтобы FTP, DNS и подобные задачи вообще присутствовали на быстрых ядрах. Чтобы на этих быстрых исполнялось лишь то, что действительно важно - MySQL и PHP. В файле службы добавляем все тот же taskset и список медленных ядер (в данном случае процессор E5-1650v4):
Можно конечно сделать обратное ограничение, повесить определенные задачи только на быстрые ядра:
MySQL будет работать замечательно и максимально возможно быстро... но лишь до поры пока нагрузка не большая и в основном однопоточная. Нужно быть осторожным т.к. если к базам будут приходить больше 4 параллельных запросов, то суммарная производительность конечно же наоборот уменьшится, ведь мы по-сути ограничили этот процесс лишь 4мя ядрами.
В целом конечно же подобные процессоры очень неудобны и гораздо лучше когда все ядра равны.
Особенно печально если ваш хостер использует подобные процессоры и вас поселят именно на подобные медленные ядра, которые никогда, ни при каких условиях не смогут приблизиться к турбо-частоте (За которую вы наверняка заплатили, поверив рекламе). И вы врядли сможете подобрать слова, чтоб объяснить/доказать проблему поддержке.
Автор: Крупченко Евгений
