Какое железо лучше для нагруженного веб-сервера?

Question

[Александр]

Имеем нагруженный вебсервер (4-5к запросов в секунду).
Связка: php-fpm (3500 воркеров статик), ngnix, memchached, redis + mysql на запись и 2 реплики для чтения.
Посоветуйте процессоры из списка для самого высокого быстродействия:

2 x Intel® Xeon® SP Gold (2шт)
Intel® Xeon® W-2295
Intel® Xeon® W-2145

Сейчас стоит AMD EPYC 7502 показывает себя не очень хорошо (сильно нагружен), высоковатый LA.

Comments

[Дмитрий]

Не думаю что интел координально все исправит, даже если взять 2 голда, это 80 потоков, кэша меньше чем у амд, и память по медленее

[Дмитрий Шицков]

По информации только о запросах как-то сложно что-то советовать.
У вас столько всего на одно сервере - что из всего этого причина высокого la? Может это высокий iowait?
У вас все реплики mysql на том же сервере? А Профит от чтения из двух реплик есть?

[Михаил]

Меня озадачивает 3500 php-fpm воркеров. Это как бы в разы больше наличных ядер процессора.
При этом 4-5 тысяч запросов в секунду. То есть, предполагая что у вас задействовано порядка 3000 воркеров (500 оставляем как резерв), то на обработку одного запроса уходит порядка 0,65 секунды. Не многовато ли?

У вас выходит порядка 55 воркеров на один поток процессора (и это я считаю только php-fpm, на деле будет больше). Это просто ужас сколько переключений между тредами (переключений контекста), что является космически дорогой операцией. Возможно что-то надо делать с этим?

[CityCat4]

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

(Как - не подскажу)

[neol]

AMD EPYC 7502 по одному они не ставятся, у вас их два или вы перепутали 7502P и 7502?

[Александр]

neol, 7502P

[Александр]

Дмитрий Шицков, io норма, реплики на других серверах. На этом только веб

[Александр]

Дмитрий Шицков, la от всего +-, но большая часть я думаю вебсервер

[Александр]

CityCat4, Из htop - Tasks: 3848, 9088thr; 19running

[Александр]

Михаил, задействовано где то 150-300 всегда одновременно

[Михаил]

Александр, а зачем их тогда столько? Погасите лишние, оставьте 300-500 (можно даже сконфигурировать динамическое количество). И посмотрите что будет с LA после этого.

[Александр]

Михаил, вообще ничего не поменялось)

[Александр]

CityCat4, то есть фактически выход только масштабировать вебсервер?

[CityCat4]

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

[Александр]

CityCat4, так а какая реализация, тут API, огромное количество запросов на него. Ничего сверхестественного, просто очень много запросов

Answer 1

[Николай Савельев]

Для нагруженных сервисов железо не так важно, важна архитектура.
Железо - это вертикальное масштабирование и оно всегда имеет ограничения, с которыми все сталкиваются через полгод-год-два. Впрочем, этот твой вопрос тому доказательство.
Надо делать упор на горизонтальное масштабирование, чтобы не зависеть от характеристик железа.
Другими словами, должно быть много недорогих (слабых) серверов, а не один дорогой и мощный.
Лично мне такой подход позволяет держать нагрузку ~24000 запросов в секунду на десяти дешёвых серверах.
Если нагрузка возрастёт, то я куплю ещё 2-5-10 дешёвых серверов вместо того, чтобы думать о характеристиках железа

Answer 2

[edo1h]

На LA вообще смотреть не стоит.
Если время генерации страничек устраивает, то всё нормально (но учитывайте, что у вас нет запаса мощности на случай наплыва пользовтелей, неудачных обновлений прграммистами и т. п.).
Если не устраивает — увеличивайте число ядер. Можно увеличить число ядер (не важно, intel или amd), но лучше смотреть в сторону горизонтального масштабирования (увеличения числа серверов). Так проще обеспечивать отказоустойчивость, дальнейший прирост производительности.