Влияние размера процессорного кэша L3 на производительность Drupal (опыт на Ryzen)

Аватар пользователя borovinskiy borovinskiy 20 января в 18:16
1

Всем привет.

У меня есть электронная библиотека "ELiS" на Drupal7 и как-то всё время использовал её при разработке и в инсталляциях на Intel/Xeon (vmware/hyper-v/bare metal), а тут попробовал дома на Ryzen 3600 в hyper-v и оказалась, что простенькая страница с минимумом логики и запросов в базу открывается не за 100-160мс, а за 30-40 мс.

Стало интересно, почему сайт на Drupal на Ryzen работает в 3-4 раза быстрее Intel/Xeon. Пришёл к выводу, что дело может быть в большом размере кеша L3 у Ryzen (32 МБ вместо типичных 12 МБ у Xeon).

Ниже кусок статьи, как к этому пришел:

graphics ryzen vs intel vs xeon for php/postgresql on drupal 7

Итак, есть разница в скорости вывода простой страницы на Drupal. В чём причина?

На разницу частот списать не получается (Ryzen - 4 ГГц, Xeon около 3 ГГц).

Там где на Xeon простая страница с 20-30 запросами в базу данных генерируется за 100-140 мс, на Ryzen за 30-40 мс.

Везде где я смотрел на производительность Drupal, используются SSD, PHP7.2, PostgreSQL 11/12, CentOS 7/8. Чаще всего ОС с Drupal была в системе виртуализации, но есть инсталляция и на чистом железе с Xeon и особо большой скорости там не заметно.

Что не должно влиять на различие в разы

  • Частота: разница не велика, обычно производительность растет линейно с частотой и может быть больше на десятки процентов, но не в разы.
  • SSD: т.к. страница находится в файловом кеше, чтения с дисков почти нет, а запись сессии - это всего 2-3 запроса.
  • Число ядер: PHP работает однопоточно, PostgreSQL тоже однопоточно на одном подключении, поэтому больше двух ядер для обработки одного запроса не нужно, да и те работают по очереди из-за синхронности PHP. При этом попадание в кеш в базе данных высокое, т.к. вначале, конечно, кеш прогревается перед измерением выдачи страницы.
  • Версия PHP, ОС, PostgreSQL: небольшие изменения производительности от версии к версии могут быть, но в данном случае изменения производительности в разы быть не могло, т.к. отличия незначительные и в основном заключаются в аппаратной платформе.
  • Влияние системы виртуализации: есть инсталляции Drupal на голом железе и там характерные скорости незначительно отличаются от Xeon c Drupal в Hyper-V.

Гипотеза: влияет кеш процессора

Возникла гипотеза, что влияние оказывает большой кеш процессора L3 в Ryzen, который в три раза больше чем на испытуемых Xeon.

В большой кеш может залезть движок PHP Zend, что может дать серьезное ускорение.

Методика тестирования

Задача состояла в том, чтобы забить L3-кеш и посмотреть, происходит ли при этом падение скорости PHP и как.

Но забить кеш надо так, чтобы это не влияло на работу ядер, обрабатывающих PHP.

Тесты проводились на Ryzen 3600, ОС Windows 10, Drupal 7 работала под управлением CentOS8 в Hyper-V.

Первый тест

Вначале написан простой скрипт, который не трогает L3 кеш, а просто утилизирует одно из ядер виртуальной машины с Drupal, суть которого заключалась в бесконечном сложении и вычитании единицы.

while (true) {
  
$i 1;
  
$i++;
  
$i--;
}
?>

Запуск теста показал, что скорость генерации страницы Drupal не изменилась, хоть одно ядро было занято на 100%, на котором был запущен этот тест.

Т.е. загрузка ядра вычислениями, не трогающими L3 кеш на генерацию страницы не влияет.

Второй тест

Идея состоит в том, чтобы прочитать файл в 400 МБ и начать его по бесконечному циклу копировать из строки в строку.

Копирование данных из строки в строку - задача не слишком тяжёлая для процессора, но хорошо утилизирующая память и занимающая кеш L3, эффективно вытесняя из него данные других процессов.

При выполнении копирования строк параллельно измеряется на этой же виртуальной машине скорость работы сайта с Drupal.

Чтобы увеличить нагрузку на кеш L3, копирование строк с помощью скрипта запускалось параллельно от 1 до 4 раз (с утилизацией 1-4 потоков) на виртуальной машине с 6 виртуальными процессорами (два процесса отведены PHP+PostgreSQL).

$file file_get_contents('test.pdf'); // 400 MB
for ($i=0$i<100000$i++) {
  
$tmp $file ' ' $i// copy string
  
$file null;
  
$file $tmp ' ' $i// copy string
}?>

Ограничение методики в том, что при копировании строки утилизируется не только кеш, но и шина данных до ОЗУ.

Результаты

При выполнении второго теста выяснилось, что увеличение числа потоков, копирующих строку и утилизирующих L3, происходит снижение скорости генерации страницы сайта на 10 мс на каждый новый поток.

Т.е. при четырех запущенных потоков скорость генерации страницы на Ryzen составляет 70 мс вместо 30 мс, когда ни одного потока копирования строк не запущено.

Обсуждение

Линейное падение скорости вывода простейшей страницы сайта Drupal от числа читающих потоков выглядит как подтверждение гипотезы о хорошем влиянии большого кеша L3 на производительность Drupal, но её следует проверить на Xeon также с большим кешем L3 (такие начали появляться, но недоступны мне для тестирования).

Поэтому предварительно есть рекомендация при выборе процессора для Drupal отдавать предпочтение процессорам с большим L3, может быть даже перед числом ядер или частоте.

Однако там где будет много данных (например для задачи обработки статистики), большой кеш может оказаться не столь эффективным, т.к. обрабатываемые данные предположительно могут вытеснять из кеша движок PHP.

Если смотреть современные линейки процессоров, то кеш L3 больше в линейке EPYC.

У кого если есть возможность протестировать на Xeon с большим кешем - прошу отозваться.

Комментарии

Аватар пользователя jura12 jura12 22 января в 1:42

я старым интел процессором не доверяю. обещали падение производительности до 30% изза патчей от уязвимостей Spectre и Meltdown. а процессор rysen 3600 новый. при техже частотах должен работать быстрее. кэш конечно важен но надо высчитывать производительность на ядро или на частоту.

Аватар пользователя borovinskiy borovinskiy 25 января в 14:22
jura12 wrote:

я старым интел процессором не доверяю. обещали падение производительности до 30% изза патчей от уязвимостей Spectre и Meltdown. а процессор rysen 3600 новый. при техже частотах должен работать быстрее. кэш конечно важен но надо высчитывать производительность на ядро или на частоту.

В Linux на Ryzen тоже заплатки показывает:

cat /proc/cpuinfo

Опять же, на сколько помню, речь при заплатках шла про падение производительности до 30% (и то не на всех задачах), а не до 300%.
Т.е. устранение уязвимостей еще могло бы объяснить разницу в процентах, но никак ни в разы.

Xeon Silver 4208 с картинки выпущен во втором квартале 2019:
https://ark.intel.com/content/www/ru/ru/ark/products/193390/intel-xeon-s...

Аватар пользователя bsyomov bsyomov 25 января в 15:47

Там падение зависит от типов нагрузки и может быть довольно большим на практике. Не 300% конечно, но это же один из факторов. 30 тут, 20 на частоте, что-то на памяти что-то на настройках, что-то за счёт архитектуры и шин, вот и набегает... У новых зеонов пока не решены проблемы для которых заплатки, там тоже есть заметное падение производительности, на райзенах с этим куда лучше.

Аватар пользователя bsyomov bsyomov 24 января в 19:59
1
borovinskiy wrote:

В большой кеш может залезть движок PHP Zend, что может дать серьезное ускорение.

Нет, не может, это не так работает.

По частоте только на 20% уже разница. + более свежая архитектура, лучшие механизмы предсказания, нет тормозных заплаток в микрокоде.

От объёма кеша процессора, тем более L3, на одной и той же архитектуре процессора, при малой конкуретности разница в производительности единицы процентов, на самом деле.

Аватар пользователя bsyomov bsyomov 24 января в 20:31
1

Вообще, чтобы тестировать такие вещи и делать подобные выводы, должен быть собран стенд, с одной и той же памятью на одной частоте, желательно, процессорами на одной частоте, с одной и той же периферией всей, и одним и тем же ПО. И вот тогда можно говорить о влиянии размера кеша. А тут могло быть причиной вообще что угодно. Более быстрая память, другая процессорная архитектура, даже настройки постгреса. Smile

Ну а из того, что вымыванием кеша можно замедлить выполнение параллельного процесса, совсем не следует, что от его размера критично зависит производительность, на самом-то деле...

В общем, за методику тестирования жирная 2.

Аватар пользователя gun_dose gun_dose 24 января в 21:54

Вот кстати да, сравнивая амд и интел, нужно помнить, что у разных производителей разные операции выполняются за разное количество тактов. А ещё непонятно, причём тут Zend. А ещё очень сомнительно, что в процессорный кэш попадёт именно ядро друпал. Да и вообще-то, прежде чем попасть в кэш процессора, php-код необходимо сперва интерпретировать.

Хотя безусловно логично, что увеличение процессорного кэша увеличивает производительность.

Аватар пользователя borovinskiy borovinskiy 25 января в 14:27

Здесь да, много предположений. Может всё несколько не так, для этого неплохо бы попробовать поискать ситуации, когда у кого-то тоже ускорение в 3-4 раза и посмотреть в чем различия.

Но давайте вспомним, что в PHP включен opcache. Т.е. байткод Drupal при повторном обращении к странице уже скомпилирован и находится в ОЗУ.

Сам движок PHP тоже где-то в ОЗУ сидит.

То, что дело в кеше - гипотеза. Если у кого-то есть Xeon c 32 или 64 МБ кеша L3 - прошу проверить и написать результаты. У меня такого камня нет.

Аватар пользователя borovinskiy borovinskiy 25 января в 14:34
bsyomov wrote:

Вообще, чтобы тестировать такие вещи и делать подобные выводы, должен быть собран стенд, с одной и той же памятью на одной частоте, желательно, процессорами на одной частоте, с одной и той же периферией всей, и одним и тем же ПО. И вот тогда можно говорить о влиянии размера кеша. А тут могло быть причиной вообще что угодно. Более быстрая память, другая процессорная архитектура, даже настройки постгреса. Smile
Ну а из того, что вымыванием кеша можно замедлить выполнение параллельного процесса, совсем не следует, что от его размера критично зависит производительность, на самом-то деле...
В общем, за методику тестирования жирная 2.

Разница в частоте ОЗУ (2.4 vs 3 ГГц) может дать разницу в 10% по производительности. Но не в разы.

Разница в частоте ЦПУ может дать +30%, но не в разы.

Народ много и часто тестил amd vs. intel на разных задачах и при одинаковых частотах и ядрах я ни в одном тесте не видел разницу в разы из-за отличий архитектур.

Вот между ARM и Intel/AMD есть разница в разы из-за разных архитектур.

В базе существенных различий нет т.к. программа ставился из одного инсталлятора и вообще результат выдается из кеша (т.е. нет сложных запросов в базу, базе надо сходить и на запрос достать из кеша ответ). Можно, конечно, профайлер включить и посмотреть время выполнения запросов в базу, но я не ожидаю здесь каких-то сюрпризов.

Аватар пользователя borovinskiy borovinskiy 25 января в 14:40

Чтобы было примерное понимание, почему кеш многое объясняет:

Задержки обращения процессора в L3 примерно в 10 раз меньше задержек обращения в ОЗУ.

Отсюда и может вылазить ускорение в разы.

Аватар пользователя bsyomov bsyomov 25 января в 15:51

Оно так, но далеко не всегда это даёт возможность процессору получить данные в 10 раз быстрее, даже если они в кеше. Так что даже если бы вся память, предположим, помещалась бы в этот кеш, и задача была бы перемешивать данные в памяти, то всё равно был бы прирост заметно меньше 10 раз. А задачи, всё же, обычно больше вычислительные.

Аватар пользователя borovinskiy borovinskiy 26 января в 1:48
bsyomov wrote:

Оно так, но далеко не всегда это даёт возможность процессору получить данные в 10 раз быстрее, даже если они в кеше. Так что даже если бы вся память, предположим, помещалась бы в этот кеш, и задача была бы перемешивать данные в памяти, то всё равно был бы прирост заметно меньше 10 раз. А задачи, всё же, обычно больше вычислительные.

Дак прирост и меньше 10 раз. 3-4 раза.

Аватар пользователя adano adano 25 января в 15:47

Да очень хороший, нужный и своевременный тест. При появлении Ryzen 5 3600, промелькнула такая мысль, а "может сервак..."
имхо, этот проц будет бестселлером

P.S. Серваки уже во всю появляются:
https://hardprice.ru/wall/201912/10367-na-desktopnyh-processorah-amd-ryz...
https://ru.hetzner.com/hosting/produktmatrix/rootserver-amd
https://coopertino.ru/arenda-servera-dedicated/

Аватар пользователя bsyomov bsyomov 25 января в 16:12

Сервера действительно появляются, и AMD первый раз за очень много лет заметно обогнала Intel, создав более технически совершенные процессоры, ещё и за разумные деньги, это факт.
Но тест отвратительный по исполнению и выводам. Smile

Кстати, по серверам стоит смотреть на AMD Epyc тогда уж.

Аватар пользователя borovinskiy borovinskiy 26 января в 1:53

Хочу только обратить внимание, что тест затрагивал крайне простой случай, когда запрос повторяется на одну и ту же страницу с минимумом логики и запросов в базу. Т.е. все берется из прогретого кеша.

В реальных рабочих нагрузках все может быть не так здорово.