Анатолий Шипицын: нет нет, отключение opcache прошло после падения fpm, сейчас уже не вспомню но поиск инфы в интенете показал что обшибка как раз таки с кешированием связана. После отключения - какое то время поработало и опять упало, но дело не в ресурсах, на сервер стоит мониторинг и если был перегруз по ресурсам это было бы видно, но это не было видно и собственно не было. Опять же из личного опыта - если я поставлю огромный размер кеша для mysql - а кеш на диске ( не в памяти) в итоге тормоза - так как идет повышенная нагрузка на диски. то же и с php, проблема не в кеше или слишком больших параметрах ( в моем случае ), так как если бы это касалось их - было бы видно просадка ресурсов в мониторинге, а этого нет (утилизация процессора, нехватка памяти, высокий IO). По поводу FPM и что что запускается один раз ? Один раз запускается главный процесс, который в свою очередь по мере надобности открывает новые обработчики запросов (процессы, потоки), кол-во которых обусловлено параметрами php-fpm, а значит разницы по сути нет, запускает обработчики apache или fpm, дальше сценарий аналогичный - материнский процесс открывает что то - что обработает запрос и выдаст ответ. Запустите php-fpm в режиме tcp-socket. натравите на него живой траф черз nginx или apache, посмотрите на поведение и увидите что разницы нет, а рассказы про скорость работы - холивар между fpm и fcgi чистой воды (имхо). Соглашусь с вами про бездумное увеличение параметров, на данный момент анализа понял, что есть еще в fcgi + apache зависимость от таймаутов дефолтных и из конфига, но до конца еще не проникся, не набрал критическую массу того - как все работает на низком уровне. Опять же про нагрузку и бездумное использование ресурсов из опыта - поставив параметр PHP_FCGI_MAX_REQUESTS = 99999 в php-wrapper - сервер сразу умер, так как не мог создать ни одного форка и это сразу стало заметно по всем мониторилкам :) и помог ребут сервера, благо апач не стартовал в автомате.
Баланс ресурсов - согласен, но он не может быть ниже чем на аналогичном сервере с аналогичным конфигом, а разница в логике работы и коде (сейчас грешу еще на код, но хочется и говнокод заставить работать, без падений процессов и сервисов, не знаю получится ли), сейчас все же мне удалось заставить клиента и его разработчиков переделать систему на отдачу статики которая генерится динамикой по определнному алгоритму и это работает, на данный момент нагрузка пока не большая, в пике около 50 запросов в секунду, но это статика и все летает, а причину падения все еще ищу....
Анатолий Шипицын: Я разницы не вижу особой между fpm и fcgi, так как по сути это одно и то же, различие лишь в том, что fpm работает как отдельный процесс, а fcgi запускается apache через mod_fcgi. Кеширование отключил так как с opcache fpm вылетел оч быстро, сейчас без кеширования работает. Ошибки что в fcgi что в fpm модуле связаны с большим кол-вом запросов и нехваткой обработчиков (я так думаю) по сути найдя какой именно параметр нужно регулировать, проблема решится в обоих режимах, на выходных буду пробовать увеличивать для fpm кол-во процессов, как и для fcgi, ну и логику 100% нужно менять, так как сервер должен обрабатывать запрос, а не перебрасывать его несколько разу туда - сюда, при этом после каждого переброса инициируется обработчик в php и потомок в apache. Еще думаю что проблема может быть связана с настройками самой ОС, так как под каждое поделючение и обработку запроса происходит создание процессов, дескрипторов, выделение ресурсов и прочие процессы, возможно тут еще нужно через sysctl какие то параметры регулировать. На счет безконтрольного запуска fcgi - не согласен, так как запуск происходит тогда - когда идет запрос на .php файл, апач через fcgi модуль обращается к php-wrapper и передает ему запрос, запуск на обработку враппера - имхо тяжелая задача, так как это происходит запуск процесса (процесс это всегда тяжело, хотя бы гялнуть на apache-prefork), а завершается процесс после обработки запроса и возвращение ответа родителю - то есть apache. Если даже процесс по какой то причине подвиснет, потеряет связь с родителем и пр.., для этого в mod_fcgi есть параметры которые задают через сколько прибить подвисший процесс, по сути так же как и с fpm. То есть процесс запуска как мне кажется совсем не хаотичных и не безконтрольный. В целом fpm режим работает по тому же принципу, разница в наличии tcp-socket в который веб-сервер передает запрос от клиента. Данный сокет принимает запрос, на обработку передает php процессору, который после обработки запроса передает ответ назад веб-серверу, обработка запроса по сути то же генерация процесса со всеми накладными расходами системных ресурсов.... В целом да - буду дальше смотреть на подкручивание пармтеров пхп, системы... Возможно стоит вспомнить институтский курс С и разобрать модуль fcgi :)
а смысл? Какая разница между fcgi и fpm ? Поставил для эксперимента nginx+php-fpm, на высокой нагрузке эта связка очень быстро треснула (сначала лег php-fpm в режиме unix socket, поставил его локал на 9000 порт, то же лег c (104: Connection reset by peer) while reading response header from upstream) - тюнинг не помог, а оттачивать не было ни желания ни времени (нагрузка 10% от ожидаемой была ~50 запросов в секунду), вернул назад на fcgi + apache2-worker. Пока все еще в поисках логического обьяснения почему периодавми падает от нехватки слотов.
Максим: вывод до заголовков вряд ли, так как оно в целом работает работает, потом резко падает. После рестарта помогает. Подозреваю что проблема может и со скриптом быть, но на столько смертельная, логика там деревянная и сводится к тому что
1. Пришел запрос на aaa.com/str1.html
2. .hraccess реврфйтит такое обращение === str1.html => script.php
3. script.php делает запрос на тот же домен на aaa.com/123.html?param1¶m2¶m3 + задает заголовки отключающие кеширование.
4. .htaccess делает реврайт === 123.html?param1¶m2¶m3 => script2.php
5. script2.php выбирает данные из редиса и отдает клиенту
Про данную логику работы, не спрашивайте у меня, программист на данный момент менять ничего не будет. Не думаю что это основная проблема, но все же есть подозрение что данная логика работы стоит в цепи событий приводящих к проблеме.
не подходит вариант, так как в этом случае права будут
644 а владелец root:dima
на данный момент стоят правана каталог:
drwsrwsrwx 3 dima dima 4096 Dec 23 13:48 nginx
созданный файл из контейнера:
-rw-r--r-- 1 root dima 0 Dec 23 13:48 ewrwerwe
Не понимаю тогда - почему система показывает что процессы докера сьедают столько ресурсов. Я понимаю php+mogrify- они в контейнере работают и кушают оч много, но у меня сложилось впечателнеи что и сами процессы докера отжирают не мало. Проверить как лучше без докера не получится, так как софт - это по сути обработчик данных - картинки, текст, парсеры и нагрузка идет по мере появления данных, а значит особого смысла не вижу.
docker stats как я понимаю показывает потребление ресурсов "в контейнере" то есть по сути то же что и top за исключением системных процессов и в итоге все равно скалдывается ощущение что показания top вполне себе реальный относительно докера.
Алексей: Ну у меня по опыту чуйка сработала что проблема не в настройках, модули себя так не ведут... А разбираться с чужим кодом при том что я не программист - дело неблагодарное. Хорошо что все разрешилось ожидаемо ))
Алексей: В общем то как и предполагал проблема была в код - только что программист подтвердил. Внятно обьяснить не могу - так как веб-программирование не мой конек. Решение проблемы если дословно "Завершил сессию перед отправкой файла. Файл отправляется последовательным чтением содержимого", я так понимаю что файл отдавался клиенту и сессия на этом не завершалась - а ждала пока закончится закачка, при этом на сервер блокировался файл сессии и в него не получалось писать когда юзер еще раз пробовал подключится, в итоге все процессы подключения в пределах этой сессии ждали когда будет снята блокировка с файла сессии на сервере. Как то так....
Walt Disney: правильно - но iptables не будет держать соединение в очереди, пока не закочнится нагрузку, на сколько я знаю iptables - он этого не умеет делать. Да и iptables не контролит apache, отдачу контента и прочее. Ну и в iptables на днный момент нет правил:
Walt Disney: Зло по имени Suhosin отсутствует, firewalld как я уже писал не будет держать запрос каким либо образом, тот же iptables если ничего нового не придумали - я ни разу не видел что бы так себя вел. Тут проблема в связке apache + php, кто то долго думает, сейчас буду дальше искать чего там и как
В каую спам базу ? Как правило у всяких Spamhaus и им подобных при попадании в базу есть и обьяснение почему адрес туда попал. У меня такое было
- Хостнг сервер - сломали акк клиента отправили 500 писем (лимит) и некоторые ушли на адреса ловушки
- Сломали сервер и с него сделали обращение на бота из ботнета zeus = сразу сервак в спамхауз залетел
- Спаси, довреи, подставные сайты (сайты по внешнему виду 1в1 как какой то другой, делают с целью выманить личную инфу), прокси, с сервака брутят ssh, админ доступы, сервак участник ботнета и прочее...
Надо смотреть чего говорят спам-листинги, а оттуда уже отталкиваться
Буду ждать утра - владелец сайта ушел спать и сменил пароль в админку, просто с сервака файлы отдаются без проблем и влюбом кол-ве, отдача файлов в админке идет через пхп скрипт... Сутра буду проверять тогда на счет инкогнито и дальше уже по ситуации...
да нету там ничего особенного, сайт не нагржен, там проект такой что нагрузка волнообразная. Настройки стоят скажем так немыслимые, а именно
php-wrapper:
Я больше грешу на php что в нем где то какие то костыли, но сам не программист и лезть в чужой код нет никакого желания, а разработчик сутки на связь не выходит. Если ближайшее время не появится придется делать глубокое погружение в чужой код, судя пот тому как на сервер сложены файлы, отсутствие порядка, коммиты прям на сервере и открытый доступ в .git по http для всех, я не знаю чего ожидать, потому проверяю что может быть еще в настройках сервера. Если учесть что RedHat решил вывернуть сисадминам мозг с выходом Centos7 - а я реально с этой версией еще не сталкивался, чего ждать не понятно, где искать то же не доконца понятно. Возможно в новой версии ОС какие то свои новые плюшки - завитушки о которых еще не знаю...
Только с этого же устройства, к сожалению на данный момент не могу проверить если с того же IP но другого устройства будет ли та же проблема - пока не знаю
лимитов нет - написал выше, по поводу max_execution_time - стоит 300, что самое интересное - если ждать 300 сек то в логах апача появляется строка
[Sun Sep 04 12:55:43.211254 2016] [fcgid:warn] [pid 4330:tid 140067506943744] (70007)The timeout specif
ied has expired: [client 1.1.1.1:55320] mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer: https://www.......
Если оборвать закачку - сразу все открывается. Такое ощущение что на уровне пхп как то проверяется и блокируется. Когда идет закачка файла - все вкладки с попытками открыть сайт висят в ожидании - как будто пхп послал запрос к прмиеру в базу и жде ответ, как только база ернула результат - сразу все прогурзилось, не похоже это на лимиты, так как если мне не изменяет память у того же nginx когда врубаешь лимиты - он на все что выше отдает или 500 или 403 по моему, но ника не держит соедиенение в очереди, а как только появилась возможность все отдалось, но nginx на сервер нет, а мдулей для включения лимитов не ставил, а в стандартной поставке они не идут включенными.
Баланс ресурсов - согласен, но он не может быть ниже чем на аналогичном сервере с аналогичным конфигом, а разница в логике работы и коде (сейчас грешу еще на код, но хочется и говнокод заставить работать, без падений процессов и сервисов, не знаю получится ли), сейчас все же мне удалось заставить клиента и его разработчиков переделать систему на отдачу статики которая генерится динамикой по определнному алгоритму и это работает, на данный момент нагрузка пока не большая, в пике около 50 запросов в секунду, но это статика и все летает, а причину падения все еще ищу....