Подскажите админа хорошего...

А какие сервисы надо настраивать, какие требования?

работа с трафиком

2 проекта на разных серверах

1ый. боты ложат весь сервер, и отключали ботов вроде и тд - все равно ложат

2ой - работа с трафиком - нужна стабильная работа и подстраховка, но .млять... снова падает сервер, 502 вызывает, типо бд перегружена

устал уже, кто поможет?

osshelp.ru стукнитесь, ребята на этом специализируются, нам не раз в настройке помогали.

TipppTop, Будет стоить очень недобрых денег, а так нет ничего невозможного:)

Опыт более чем есть в подобных проектах, постоянное администрирование без проблем, стучите в телеграм: @kxkwork

Четыре сервера соединены между собой гигабитным LAN одним интерфейсом, вторым интерфейсом смотрят в WAN. СentOS 7.

Два сервера из них - не дорогих. По слабее. Являются балансерами (balancer1 и balancer2) трафика на два сервера-воркера, по-дороже (worker1 и worker2).

Подняты на балансерах IPVS+Keepalived (ДЦ нормально относится к arp-пакетам в рамках одного LAN-сегмента), которые шлют пакеты на два воркера на 80ый и 443й порты.

IPVS был выбран, а не haproxy , так как ДЦ считает трафик при перерасходе, поэтому отдавать трафик нужно сразу клиенту, с воркеров, то есть реализован DSR (direct service return).

На воркерах поднят nginx + php-fpm (5.6.30), они принимают соединения от балансеров. Синхронизация файлов c worker1 на worker2 - lsyncd по гигабитному LAN.

limits.conf и sysctl.conf задраны нормально. FPM на воркерах ждет соединения на сокете а не на IP:port. rrDNS на keepalived-адреса балансеров.

pm у FPM в ondemand. Данная хема обкатана за много лет на проектах, с посещением в несколько миллионов в сутки. Redis и MySQL - мало нагружены, находятся в стороне на одном из балансеров. Их я проверил первыми, может быть они не отвечают на запросы php - там все ровно, тишь да гладь. Не большая нагрузка.

Периодически течет память от FPM на воркерах, соответственно сайты, которые на них проксируются - отдают 502. Проблема приходит как-то фантомно. Не ясно - почему и от чего. PHP уже отстукивает в newrelic сегодня целый день, программист со мной вместе пялится в newrelic и не видит проблем.

Некоторые сайты ходят через приватные прокси, tcpdump'ом смотрел на трафик до прокси. RST нет, таймаутов нет. Прокси действительно нормальные. Хорошо работают. Хотя я допускаю, что они могут залипать.

Трафик летит копеечный на балансеры, по 2-3Мбит\с. С воркеров по DSR уходит так же копеечный - 6-8Мбит.

Я так же не вижу проблем с точки зрения архитектуры. Из-за падающих сайтов собственник проекта нервничает. Сомневается в моей компетентности.

Перезагружать FPM по крону и всякие drop_caches - для школьников от вредных советов. Подобное прошу не советовать. Зуб нужно лечить, а не пить обезболивающие.

Приветствуется критика, вопросы, что я не учел, что я пропустил?

Если проблема повторится - ничего трогать не буду. Отдам за свой счет на разовый аудит компетентному администратору из этой ветки.

Аргументы собственника: "у нас на одном сервере со сраной vesta все работало!!!".

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

только подтверждает вышесказанное.

Стукнитесь - их профиль как раз, и связку nginx+php-fpm отлично знают, ведь с ней же у вас проблемы, видно что подтекает сильно по графикам... По кластеру могут подсказать также, и hi-load решения есть в портфеле. По цене не подскажу - у них почасовка, все проблемы с которыми мы приходили стоили меньше стоимости аренды сервера в месяц.

pupseg, PHP при утечках в stderr должен писать отчет. Есть что-то в нем? report_memleaks = 1 ? pm.max_requests не 0?

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

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

1) Почему Nginx считает пулы "bad gateway" удалось прояснить? FPM-пул вообще коннект не принимает, принимает и сразу сбрасывает? Хотя бы для своего адреса включите debug_connection и потыкайте в код в момент залипания. В debug'е из error лога возможно что-то полезное будет. Отсюда уже N возможных вариантов.

2) Что в момент 502й с master'ом и child'ами? Продолжают шевелиться (и жрать проц), висят в холостую или вообще залипли? В условиях высокого RPS проблематично, но иногда все же удается что-то полезное вытащить, зацепившись strace/ltrace на какой-то из child'ов.

3) Child'ы падают в момент 502й или нет? Есть в dmesg про SIGSEGV и иже с ними? Если да, то включить coredump и попробовать с gdb заглянуть под капот. Так можно найти кто именно течет (может какой из PECL модулей).

Ну и эксперимента ради переключите один из сервер с ondemand на dynamic. Так возможно будет чуть проще зацепиться к кому-то из child'ов и посмотреть что он там творит.

Плюс никто не мешает поднять рядом еще один пул один в один на другом порту и в nginx в upstream добавить его как backup. Так вы получите возможность спокойно тыкать палочкой в умерший FPM-пул, когда траф будет молотить еще пока рабочий "запасной" пул.

Надеюсь не зря влез в топик и хоть что-то из этого будет полезно :)

PS: Кстати, третий сценарий хоть и выглядит "мифическим", но мы видели ситуации, когда fpm или mod_php5 спустя некоторое время работы начинает крэшиться только на части сайтов. Причем остальные сайты и тестовые скрипты в этот же момент работают прекрасно. Раскопали, что крыло один из PECL модулей, но апдейтов для этой ветки PHP не было. Поэтому разработчики клиента решили в качестве workaround поменять проблематичный кусок кода. Да, некошерно и коряво, но бизнес решил свою "проблему".

Если не секрет о какой посещаемости речь?

О небольшой... воркеры где-то по 15 мбит\с отдают каждый.

А в униках, или в каких-то еще попугаях - хз. В них только SEO'шники считают.

---------- Добавлено 22.06.2017 в 07:53 ----------

OSSHelp, Предположу, что описанную схему ваша компания не будет рисовать за 100$ :) и даже за 200$ не будет :) :) :)

Спасибо за комментарий, сейчас вникну, еще не проснулся.

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

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

Ни о каких VPS, контейнерах и т д речи даже не может быть - все это глупости.