20 января 2020 в 18:16
Всем привет.
У меня есть электронная библиотека "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).
Ниже кусок статьи, как к этому пришел:
Итак, есть разница в скорости вывода простой страницы на 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, суть которого заключалась в бесконечном сложении и вычитании единицы.
<?php
while (true) {
$i = 1;
$i++;
$i--;
}?>Запуск теста показал, что скорость генерации страницы Drupal не изменилась, хоть одно ядро было занято на 100%, на котором был запущен этот тест.
Т.е. загрузка ядра вычислениями, не трогающими L3 кеш на генерацию страницы не влияет.
Второй тест
Идея состоит в том, чтобы прочитать файл в 400 МБ и начать его по бесконечному циклу копировать из строки в строку.
Копирование данных из строки в строку - задача не слишком тяжёлая для процессора, но хорошо утилизирующая память и занимающая кеш L3, эффективно вытесняя из него данные других процессов.
При выполнении копирования строк параллельно измеряется на этой же виртуальной машине скорость работы сайта с Drupal.
Чтобы увеличить нагрузку на кеш L3, копирование строк с помощью скрипта запускалось параллельно от 1 до 4 раз (с утилизацией 1-4 потоков) на виртуальной машине с 6 виртуальными процессорами (два процесса отведены PHP+PostgreSQL).
<?php
$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 с большим кешем - прошу отозваться.
Комментарии
я старым интел процессором не доверяю. обещали падение производительности до 30% изза патчей от уязвимостей Spectre и Meltdown. а процессор rysen 3600 новый. при техже частотах должен работать быстрее. кэш конечно важен но надо высчитывать производительность на ядро или на частоту.
В Linux на Ryzen тоже заплатки показывает:
Опять же, на сколько помню, речь при заплатках шла про падение производительности до 30% (и то не на всех задачах), а не до 300%.
Т.е. устранение уязвимостей еще могло бы объяснить разницу в процентах, но никак ни в разы.
Xeon Silver 4208 с картинки выпущен во втором квартале 2019:
https://ark.intel.com/content/www/ru/ru/ark/products/193390/intel-xeon-s...
Там падение зависит от типов нагрузки и может быть довольно большим на практике. Не 300% конечно, но это же один из факторов. 30 тут, 20 на частоте, что-то на памяти что-то на настройках, что-то за счёт архитектуры и шин, вот и набегает... У новых зеонов пока не решены проблемы для которых заплатки, там тоже есть заметное падение производительности, на райзенах с этим куда лучше.
А ядро восьмёрки в этот кэш поместится?
PHP must be set up with a minimum memory size of 64MB
Нет, не может, это не так работает.
По частоте только на 20% уже разница. + более свежая архитектура, лучшие механизмы предсказания, нет тормозных заплаток в микрокоде.
От объёма кеша процессора, тем более L3, на одной и той же архитектуре процессора, при малой конкуретности разница в производительности единицы процентов, на самом деле.
Вообще, чтобы тестировать такие вещи и делать подобные выводы, должен быть собран стенд, с одной и той же памятью на одной частоте, желательно, процессорами на одной частоте, с одной и той же периферией всей, и одним и тем же ПО. И вот тогда можно говорить о влиянии размера кеша. А тут могло быть причиной вообще что угодно. Более быстрая память, другая процессорная архитектура, даже настройки постгреса.
Ну а из того, что вымыванием кеша можно замедлить выполнение параллельного процесса, совсем не следует, что от его размера критично зависит производительность, на самом-то деле...
В общем, за методику тестирования жирная 2.
Вот кстати да, сравнивая амд и интел, нужно помнить, что у разных производителей разные операции выполняются за разное количество тактов. А ещё непонятно, причём тут Zend. А ещё очень сомнительно, что в процессорный кэш попадёт именно ядро друпал. Да и вообще-то, прежде чем попасть в кэш процессора, php-код необходимо сперва интерпретировать.
Хотя безусловно логично, что увеличение процессорного кэша увеличивает производительность.
Здесь да, много предположений. Может всё несколько не так, для этого неплохо бы попробовать поискать ситуации, когда у кого-то тоже ускорение в 3-4 раза и посмотреть в чем различия.
Но давайте вспомним, что в PHP включен opcache. Т.е. байткод Drupal при повторном обращении к странице уже скомпилирован и находится в ОЗУ.
Сам движок PHP тоже где-то в ОЗУ сидит.
То, что дело в кеше - гипотеза. Если у кого-то есть Xeon c 32 или 64 МБ кеша L3 - прошу проверить и написать результаты. У меня такого камня нет.
Разница в частоте ОЗУ (2.4 vs 3 ГГц) может дать разницу в 10% по производительности. Но не в разы.
Разница в частоте ЦПУ может дать +30%, но не в разы.
Народ много и часто тестил amd vs. intel на разных задачах и при одинаковых частотах и ядрах я ни в одном тесте не видел разницу в разы из-за отличий архитектур.
Вот между ARM и Intel/AMD есть разница в разы из-за разных архитектур.
В базе существенных различий нет т.к. программа ставился из одного инсталлятора и вообще результат выдается из кеша (т.е. нет сложных запросов в базу, базе надо сходить и на запрос достать из кеша ответ). Можно, конечно, профайлер включить и посмотреть время выполнения запросов в базу, но я не ожидаю здесь каких-то сюрпризов.
Чтобы было примерное понимание, почему кеш многое объясняет:
Задержки обращения процессора в L3 примерно в 10 раз меньше задержек обращения в ОЗУ.
Отсюда и может вылазить ускорение в разы.
Оно так, но далеко не всегда это даёт возможность процессору получить данные в 10 раз быстрее, даже если они в кеше. Так что даже если бы вся память, предположим, помещалась бы в этот кеш, и задача была бы перемешивать данные в памяти, то всё равно был бы прирост заметно меньше 10 раз. А задачи, всё же, обычно больше вычислительные.
Дак прирост и меньше 10 раз. 3-4 раза.
Да очень хороший, нужный и своевременный тест. При появлении 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/
Сервера действительно появляются, и AMD первый раз за очень много лет заметно обогнала Intel, создав более технически совершенные процессоры, ещё и за разумные деньги, это факт.
Но тест отвратительный по исполнению и выводам.
Кстати, по серверам стоит смотреть на AMD Epyc тогда уж.
Хочу только обратить внимание, что тест затрагивал крайне простой случай, когда запрос повторяется на одну и ту же страницу с минимумом логики и запросов в базу. Т.е. все берется из прогретого кеша.
В реальных рабочих нагрузках все может быть не так здорово.