Сервер под большую нагрузку, безотказная работа?

Question

[Сергей Добряк]

Всем привет!
Хочу задать такой интересный вопрос на который уже долго не могу найти ответ.
В администрировании мало что шарю поэтому прошу помощи.

Есть сервер
характеристики:
CPU: 2xXeon L5520
RAM: 24Gb
PORT: 1Gb / s
php: 7.2
Также используется MySQL
Веб-сервер Apache
ОС: Debian 9.x

Вопрос такой, как настроить сервер чтобы он выдерживал одновременный онлайн 1000 человек +
Загонял тестовый трафик сервер начинал подвисать когда было 470 человек, а падал когда было 600 человек.
Дайте какие-то советы для того чтобы сервер работал стабильно 24/7 под нагрузками, заранее спасибо!

Comments

[GavriKos]

Чтобы давать какие бы то нибыло советы - надо знать что за операции вообще выполняет сервер, а еще лучше - на каких именно операциях начинает расти нагрузка.
Может у вас там гигантские выборки из БД, или наоборот - крипту майните на ПХП.

В общем - включаете профайлер, смотрите что грузит, эту точку и оптимизируете.

[Владимир]

Ну так перед тем как загонять тестовый трафик надо было мониторинг настроить.
А то нагрузку дали а посмотреть что привело к отказу не посмотрели....

[Дмитрий]

Apache заменить на nginx+php-fpm

[Александр Филиппенко]

Посмотрите в код. Средний магаз на Битриксе, на таком железе, 1000 человек должен легко держать. А Битрикс - далеко не идеал оптимизации)

Answer 1

[Sanes]

Обратиться к компетентым специалистам. Как еще...

Answer 2

[Виктор Таран]

В первую очередь все зависит от движка, качества сборки, качества кеширования, и множества других мелких факторов.
В среднем на проект удается увеличить его производительность раза в 2-10 в зависимости от проекта.
В любом случае нужно смотреть на проект.
Правильно оптимизированные настройки хостинга могут дать сами по себе более чем ощутимый прирост, не говоря уже о стабильности тяжелых хитов под нагрузкой.
НО если акцентировать только на железо то есть пара пунктов, придерживаясь которых можно болие или менее иметь хороший результат.
1. частота ядра лучше чем количество ядер.
2. SSD - это даже не обсуждается, однако NVme - это то на что вам нужно смотреть.
3. Покажите проект.
Что касается представления php Nginx+php-fmp однако мы не часто используем такой вариант
Как правило все -же более классический nginx+apache+mod_php или nginx+apache+php-fmp.

Comments

[FanatPHP]

"Что же касается езды на автомобиле, то мы используем более классический вариант - на крышу машины прикручиваем велосипеды, садимся на эти велосипеды, а машина нас везет"

А теперь попробуйте объяснить присутствующим здесь разработчикам, зачем в связке nginx+php требуется apache. Мы с огромным интересом послушаем.

[Виктор Таран]

FanatPHP, Ну коль вы выбрали столь предсказуемый способ общения, то пожалуй я его и продолжу.
Программистам вашего уровня должны знать о том что Апач поддерживает .htaccess
самих .htaccess по сайту может быть множество, да и когда у вас в нем 12К строк редиректов не особо хочется его трогать.
А так же не все хостинг поддерживают nginx +fpm
А так же перенос высоконагруженного проекта всегда трабл, особенно с библиотеками и тд, да все возможно но отнють не всегда овчинка стоит выделки.
А так же есть "решения" например bitrix VM и Birix24, желаю удачи на чистом nginx, оно конечно если задаться целью, все заработает. но экономическое обоснование в этом отсутствует напрочь.
В результате программисты вашего уровня, подходят к линукс архитекторам, моего уровня, и жуют сопли.
если бы nginx+fpm была бы панацеей то ей бы все давно пользовались.

nginx+php-fpm - хороший вариант, но не единственный.

[FanatPHP]

Ну конечно же .htaccess! Как я мог забыть про Самый Главный Файл РНР разработчика :)
Ну и переход от гордого "мы не часто используем" к скромному "не все хостинги" и "все бы давно пользовались" немного предсказуем.

Интересная, должно быть, профессия - "линукс архитектор". И востребованная. Специалисты по размещению пхп скриптов на шаред хостингах нынче нарасхват.

[Fafhrd]

Говорить про множество хтаксессов и рассуждать о производительности и её оптимизации это 5.
Про "не все хостинги" очень интересно, особенно когда ТС пишет про свой собственный сервер.

[Виктор Таран]

для начала, востребованным php разработчикам не плохо было бы придерживаться вопроса

[Виктор Таран]

Fafhrd, собственный сервер по вашему это LAMP ?

[Sanes]

FanatPHP,

А теперь попробуйте объяснить присутствующим здесь разработчикам, зачем в связке nginx+php требуется apache. Мы с огромным интересом послушаем.

Чтобы было. Не всё решается одним nginx. PHP-FPM тоже прожорливый, не забывайте об этом.

[Fafhrd]

Виктор Таран, lamp потому, что так написано в стартовом топике, и про железо там написано. нет никакого хостинга, который что-то там не поддерживает.
и опять и снова, не надо придумывать что-то сверху стартового топика

[stratosmi]

FanatPHP,

А теперь попробуйте объяснить присутствующим здесь разработчикам, зачем в связке nginx+php требуется apache. Мы с огромным интересом послушаем.

А вы точно входите в число грамотных разработчиков?
На таком железе на таком количестве пользователей если уж есть затык, то затык отнюдь не в том, что "Apache vs nginx".

[Elmo Sputterspark]

Fafhrd,

Говорить про множество хтаксессов и рассуждать о производительности и её оптимизации это 5.

Он 300 rps считает высокой нагрузкой.

[FanatPHP]

Sanes, не нужно засорять ветку бессмысленными комментариями.
stratosmi, точно. И кроме этого мне хватает интеллекта не приписывать собеседнику слова, которых он не говорил. Берите пример.

[Sanes]

FanatPHP, это как раз вас касается. Не надо учить других, какими технологиями пользоваться. Сказали надо, значит надо.

[FanatPHP]

Sanes, вас, похоже, надо учить читать реплики, на которые вы отвечаете. Приходите, когда научитесь отвечать реальному собеседнику, а не воображаемому.

[Sanes]

FanatPHP,
Вот давайте, вы свои слова хотя бы научитесь читать, потом поговорим.

А теперь попробуйте объяснить присутствующим здесь разработчикам, зачем в связке nginx+php требуется apache. Мы с огромным интересом послушаем.

Answer 3

[Пума Тайланд]

Nginx phpfpm
Ну и придется код переписать чтобы оно держало нагрузку

Answer 4

[stratosmi]

Есть сервер
характеристики:
CPU: 2xXeon L5520
RAM: 24Gb
PORT: 1Gb / s
php: 7.2
Также используется MySQL
Веб-сервер Apache
ОС: Debian 9.x

Вопрос такой, как настроить сервер чтобы он выдерживал одновременный онлайн 1000 человек +
Загонял тестовый трафик сервер начинал подвисать когда было 470 человек, а падал когда было 600 человек.
Дайте какие-то советы для того чтобы сервер работал стабильно 24/7 под нагрузками, заранее спасибо!

Просто обратиться к разработчику.
Но к квалифицированному.

Пример из жизни - есть сервер:

виртуалка, 2 ядра, 512 мегабайтов оперативной памяти.
Держит 10 000 одновременных подключений.

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

Лучше - разработчик.
Но можно и админу.

Если вы админ и не разработчик и не можете залезть внутрь ПО, то хотя бы так: задача админа - провести профилирование - то есть выяснить где именно узкое место: не хватает процессора или памяти или скорости диска.

Такое, что "просто сервер тормозит" - это не ответ.
Всегда есть какое-то вполне определенное узкое место.

Вангую - работа с БД.
Как правило затык в говнософте, которое не корректно работает с СУБД.
А у БД, в свою очередь, самое узкое место - это диски.

Из говнокода в Highload. Используем ТАРАНtool. 5 р...

Answer 5

[Fafhrd]

Либо обратиться к специалисту, но настоящему, а не псевдо, либо проводить аудит самостоятельно и отвечать на вопросы:

- какой компонент системы(база, пхп, веб-сервнр) больше всего тормозит при 470 юзерах
- что с этим сделать, чтоб не тормозило
далее исправлять

и так по кругу, пока не станет хорошо

Answer 6

[⚡ Kotobotov ⚡]

у тебя есть несколько вариантов, первый ускорять обработку отдельного запроса, смотреть где у него бутылочное горлышко и тд (перейти с интерпретируемых языков на компилируемые, часть данных уже держать в оперативной памяти а не читать их откуда-то), это может поднять производительность в десятки а то и сотни раз.
второй - это выстраивать параллелизацию обработки запросов, менять схему обработки этих запросов с синхронных на асинхронные, складывая отдельные тяжелые задачи в отдельную очередь которая бы НЕ блокировала обработку простых запросов пользователей (это тоже может поднять производительность в десятки раз)
В любом случае это задача разработчиков твоего сервиса -> просто "настраивать" сервер, особо выхлопа не даст, можешь например увеличивать память, менять диски, вместо 10 ядерного 20 ядерный процессор поставить и вообще никакого прироста не увидеть просто НОЛЬ.