Какую настройка сервера нужно провести перед большой нагрузкой ?

Первое что нужно сделать как я понимаю, поставить nginx как frontend в apache. Какие еще настройки для оптимизации настроек БД и ОС посоветуете?

Tagged with →  

56 Responses to Настройка сервера на highload

  1. Afuen:

    Прогони например apache benchmark 🙂
    А дальше узкие места устранить.

  2. DSLPhone:

    — Отдай статику nginx-ом
    — Базу проработай mysqltuner.pl
    — Проверь нет ли медленных запросов в базе (ключ slow query)
    — Хорошо бы использовать memcached
    — Стек TCP/IT без знаний лучше не трогать.
    от слов блого-хаброэффекты воротит

  3. NitMega:

    Если всё станет совсем плохо и апач начнёт захлёбываться — можно включить кеширование nginx-ом проксированных ответов.

  4. TcuUnix:

    Если ждешь такой эффект например на главную страницу, можно заморочиться с генерированием главной страницы по крону раз в минуту, сохранением ее «на диск» и отдачей уже как статики.

  5. RatZero:

    varnish в прослойку между апачем и nginx вставить.
    натрави ab -с 100 -n 10000 http://твойхост/ — в это время посмотри нагрузку общую, mtop, лог запросов медленных, iotop, vnstat
    если все ок, то поднимай до 300 потоков и т.д. пока не упрешься во что-то в системе.
    когда упрешься — тогда и понятно будет что надо тюнить

  6. 171Phone:

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

  7. RatZero:

    стат файлы не нужны, если есть кэш. самый простой вариант = это натравить nginx на мемкэш (в качестве ключа url брать), при отсутствии в мемкэше данных — валим на apache. из минусов — надо отделять локейшенами страницы которые зависят от пользователя (кабинет и т.п.). Если сайт = блогу где нет реги, то идеальное решение. мемкэш только на сокет повесить

  8. NitMega:

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

  9. VanNix:

    Если имеешь дело с PHP — поставить APC или eAccelerator

  10. RatZero:

    Если у автора еще не стоит на фронте nginx, то решил не грузить «куками»

  11. TcuUnix:

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

    В общем есть ли решения, которым всё равно что за сайт у нас вертится и которые каким нить умным способом определяют можно ли отдать страницу из кэша или обязательно проксировать на бэк?

  12. V-nSport:

    апач вообще лишний

  13. RatZero:

    универсального решения нет, так как в рот имели всех разработчики всяческих систем кэширования, что бы обслужить всякие cms системы и скрипты и т.п.
    особо жопа, если у тебя на каждой странице есть кусок профиля пользователя, хотя бы «приветствую, Мудецкий Мудосран (выход)», или кэшировать всю страницу или по кускам и через ssi к примеру собирать — но это отдельная тема.

    под хабраэффектом многие подразумевают «ща как мулиён прийдет», а на деле тыс 2-3 ломанется за час и все… т.е. умея отдавать по 20-30 запросов в секунду (канала то хватит?) получим спокойную работу.

    сайт покаж или сам на http://loadimpact.com/ тест заколоти

  14. NitMega:

    Да не вопрос. При авторизации юзера вешаем ему куку — отдельную. А nginx учим при наличии куки проксировать, при отсутствии — доставать из кеша.

  15. RatZero:

    как вариант: на странице посадочной после логина и вешать куку (хоть куском js в теле страницы )

  16. TcuUnix:

    дело в том, что мне «не вот прям сейчас надо», но переодически появляются «веб-мастера» которые «мы тут свояли %sitename% на %cms-name% а он на VPS тормозит, помоги», а вникать во все это ну совсем не хочется, я не позиционирую себя как веб-девелопера.

    А так у меня есть drupal7 и wp на которых я экспериментирую, там канал в 10Мбит, nginx+php-fpm и они более менее справляются. Drupal дает ~10 запросов/c и упирается в cpu (хотя кэш включен), wp дает 150 на анонимуса и упирается в сеть.

    Веселые картинки:
    nload при тесте WP

    htop на drupal

    Первые пики — drupal, 2 последних WP (раньше на друпале iowait было какое то нереальное)

    Drupal сеть вообще почти не напрягает

    Если что: парсер лох.

  17. TcuUnix:

    Пик на последнем графике — тест WP.

  18. V-nSport:

    ты мне показыаешь тест, где апачеёб, который этого не скрывает, тестирует на домашней однопроцессорной тачке апач и фпм через неоттюненные юникс-сокеты, сконфанный на маленькое число воркеров, и в нём все апачи всё равно воссосали? тест проходил в 60 потоков, что равнозначно простою сервера. при этом ещё пишет:

    С другой стороны, в PHP-FPM довольно красиво реализована схема chroot’а и запуска из под отдельных юзверей, что повышает безопасность. Но он проигрывает в IPC, т.к. пока не умеет изменять количество воркеров пропорционально нагрузке. Если поставить слишком много воркеров, будет overhead по CPU и памяти (за что грешат на апач), если поставить слишком мало — будут отказы в обслуживании.

    Слишком «хорошие» начальные и конечные показатели monitor.pl отбрасываются.

    так вот теперь вопрос: ты всерьёз это?

  19. RatZero:

    это все что поможет друпалу

  20. RatZero:

    Stephan-V: ну дрочили у нас админы на 16 ядерном серваке оба варианта. разница в проценты считанные, апач больше жрет память. на том и послали всех нахуй с холиварами и если нужен htaccess, то ни кто пальцем не двинет что бы под nginx переписать правила.
    обычно не в апач упирается все, а заниматься тюнингом мелкий vps — смысла не имеет (уж если трафик под 20 r/s то денег на сервантик быть должно.)

  21. V-nSport:

    ты такой смешной, ахаха, прекрати. нет никаких холиваров, есть просто инструменты, продиктованные задачами.
    ну дрочили у нас админы на 16 ядерном серваке оба варианта
    авторитетное тестирование от группы админов локалхоста.
    и если нужен htaccess
    зачем?
    то ни кто пальцем не двинет что бы под nginx переписать правила
    ты выдвигаешь профнепригодность ваших админов как аргумент против нормальных подходов?
    заниматься тюнингом мелкий vps — смысла не имеет (уж если трафик под 20 r/s то денег на сервантик быть должно.)
    ерунду прогнал. 20 rps можно выдать влёгкую на впс

  22. TcuUnix:

    на этом этапе я соснул. Файлкэш не заводиться потому что у меня не апач, а мэмкэш не стартует потому что глибс старый, а ребутнуть «сервер» (что бы глибс обновился) нельзя потому что сам он не поднимется из за кривой матери.

  23. 171Phone:

    идеальное решение это Varnish + ESI. Там бэк конечно должен уметь отдавать правильные куски кода. Но после того как девы пролили кучу крови и пота, а админы настроили, такая комбинация способна вытянуть очень много. Плюс всякие приятные побочные еффекты типа: у нас фатальная ошибка в каком-то сранном куске внизу страницы, но сама страница не падает, а только выключает тот самый кусок. Короче дело весьма приятное.

  24. TcuUnix:

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

  25. RatZero:

    Stephan-V: я против избыточной оптимизации. Если у меня есть проект с посещалкой в 1 млн, то скорость появления нового функционала мне более важен, чем ебатня по оптимизации. Много джойнов? — поставим второй sql сервер. Если через htaccess удобно работать сеошникам (редиректы 301, к примеру) то пусть работают, нехер трогать других сотрудников. Железо стоит дешево и окупаеся своей производительностью в разы.

  26. NasUnix:

    Народ а поясните мне про iptables.
    А то я тут натравил ab на свой софтец и он вполне ожидаемо для меня рухнул. Т.е. на каких-то разумных значениях он работает и не чихает, но если слать ему 100500 запросов то падает. Мысль возникла — ведь так любой может сделать. А положить сайт с одной машины это даже как-то не смешно.

    Погуглил-погуглил и нашел такой вот вариант:
    http://sysextra.blogspot.ru/2010/11/usin

    После применения сайт работает под любым ab. Load average может вырасти до 5-6, но все работает очень быстро все-равно.
    Вопрос, чем плохо это решение?

  27. V-nSport:

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

  28. RatZero:

    Stephan-V: нехуй сеошников пускать в конфиги. 90% этих долбоебов положат сервак экспериментами

  29. RatZero:

    на уровне nginx зарезать лимитом можно еще

  30. TcuUnix:

    еще можно правило для fail2ban написать которое будет мониторить колво запросов с 1 ip и кидать его в iptables при большом колве запросов, но что то мне подсказывает что оверхед большой получиться.

  31. RatZero:

    ну вот какие нить пользователи провайдера тупого ломанутся через пул из 10 его ip и жопа

  32. TcuUnix:

    тык, а какая раздница положат твое приложение 1000 пользователей с 1 ип или 1 пользователь с аб. Задача ведь — недопустить падения для всех пользователей пожертвовав частью

  33. RatZero:

    если использовать ограничение по ip то ты теряешь пользователей сегментами. вообще это не выход. на крайняк cloudflare подключить

  34. KNTon:

    > Железо стоит дешево и окупаеся своей производительностью в разы.
    Это не повод использовать апач вместо nginx
    > Много джойнов? — поставим второй sql сервер.
    Ебать разработчиков за такую хуйню надо, а не второй сервер ставить.

  35. 171Phone:

    nabor_bukv: как же я рад, что мы не работаем в одной команде.

  36. HtoUnix:

    ох бля.

  37. KNTon:

    зачем ребутать сервер непонятно
    почему бы не поставить старый мемкеш
    ты странный

  38. RatZero:

    nabor_bukv: ебать разрабов за то, что еще ни кто не решил алгоритмически и что sql сервак по определению не может без джойнов? задачи разные бывают и число джойнов — не вина разраба порой.
    Разрабы делают быстро и с достаточной степенью качества свою работу, которая приносит мне кучу денег, уж новый сервер/стойка — это мелочи.
    Лучше за неделю сделать релиз и за вторую неделю его оттестировать и начать зарабатывать, чем 1 неделю проектировать, 2 программить и 2 тестить.
    Корпорации большие могут себе позволить говно тянуть за яйца в длинный ящик по пол года что бы выпустить продукт. В условиях недостатка средств чем быстрее проверишь продукт на живых людях, тем меньше затрат в случае факапа

  39. KNTon:

    всё должно быть сообразно, если ты уже замечаешь нагрузку, то её нужно уменьшить что-то переделав/оптимизировав, если ты нагрузку не замечаешь, то и делать ничего не надо. А тупо добавлять ресурсов ни о чём не задумываясь — вперёд, видимо это ваш выбор.
    > как же я рад, что мы не работаем в одной команде.
    я работаю только с профессионалами, нам с тобой любом случае не по пути

  40. KNTon:

    Я же написал, что по возможности надо пытаться оптимизировать, а не плодить сущности. Эта оптимизация не избыточна. Если некуда уже, то добавлять, естественно.

  41. RatZero:

    nabor_bukv: переделки дороже железа порой.
    к примеру на одном из текущих проектов каменты древовидные строчат пачками(а предполагалось, что больше читать будут статьи) и переделка модуля комментариев с текущей интеграцией и переделкой много чего — это 2 недели работы прогера/тестировщика + менеджерские затраты+ офис+ отпускные (они считай что всегда есть в затратах) + налоги = более 150 тыс рублей + тормоза на 2 недели по 1 работнику.
    вынесли каменты на отдельный сервак, который обошелся в 60 тыс рублей.

  42. KNTon:

    Мы про оптимизацию или рефакторинг?

  43. RatZero:

    nabor_bukv: оптимизировать на уровне применения наработанных практик — это имхо не оптимизация уже, а простая работа опытных людей.

  44. 171Phone:

    nabor_bukv: я рад, что мы пришли к единому мнению 😉

  45. 171Phone:

    nabor_bukv: если джоины есть, то ты их так просто не уберешь. Нормализация существует не потому что разработчики хуёво работают, на это есть серьёзные причины. Это не «хуйня» за которую надо «ебать» разработчиков. Такой подход выходит компании намного дороже чем добавление нового железа.

    Я исхожу из того, что ты работаешь с профессионалами, как ты сказал. Если ты работаешь с быдлокодерами которые не понимают как устроена RDBMS, то тогда такой подход вполне понятен.

    И не надо пожалуйста делать выводы, что я не «профессионал» не имея для этого достаточной информации. Звучишь как истеричка.

  46. 171Phone:

    ESI означает Edge Side Includes. Технология изначально разработаная в Akamai, затем портированая на Varnish. Там всё сводится к тому, что можно кэшировать не страницу целиком, а еще и отдельные блоки. Конечный HTTP body собирается на кэш сервере из кусков разной свежести.

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

    В друпал есть какая-то интеграция (http://drupal.org/project/esi), но у меня нету опыта имено с друпалом поэтому не могу сказать насколько она полная и стабильная. В любом случае нужна будет поддержка разработчиков, чтобы это дело интегрировать.

  47. RatZero:

    еще погуглить это и работу с ним nginx

  48. 171Phone:

    с SSI не работал, не знаю насколько там всё хорошо с кэшем. Всё таки varnish это специализированый frontend cache. Но может связка Nginx + SSI будет хорошо работать. Попробуешь, рассказывай.

  49. 171Phone:

    это в теории 🙂

  50. Gibno:

    это решение, как и любой костыльно-изолентный метод, плохо своей негибкостью, дубовостью. Но в качестве примитивного базового варианта на крайний случай — подойдет. Если совсем уж лень заморачиваться.
    Хотя уже сказали, есть ведь специальные сервисы, которые профессионально (и до некоторой степени — бесплатно) сделают все за тебя.

  51. Eubef:

    Настроенный imageMicro caching в Nginx Решает большинство *-эффектов.

Добавить комментарий