сервернотекучее 15.02.15 14:08 // оригинал
Утром в среду сервер вдруг решил уйти в себя, отрапортовав в логах о закончившихся файловых дескрипторах (их там 1536 на всю виртуалку). Лог в панели менеджера VDS показал, что действительно за последние сутки их уровень вдруг стал медленно, но верно расти с привычных 30-40%, добираясь в итоге до сотни. В настройках, естественно, перед этим ничего не менялось. Перезагрузил, воткнул мониторинг kern.openfiles с принудительным ребутом в случае приближения к критическому уровню. Уровень этот наступил под следующее утро. Воткнул разбор результатов procstat -af (в этой виртуалке более приличные варианты не срабатывают), чтобы видеть, какой процесс сколько отжирает, подкрутил аппетиты апача, nginx, mysql, стал смотреть. Картина забавная - сразу после перезагрузки сумма выдачи procstat слегка опережает kern.openfiles, по мере работы оба значения постепенно растут и выравниваются, подбираются к тем самым 30-40%, после чего kern.openfiles начинает уходить в отрыв, постепенно добираясь до лимита.
Стал всерьез задумываться о принудительном ребуте в 5 утра (некрасиво, да, но лучше, чем ребут на пике дневной посещаемости), но после следующего ребута все внезапно рассосалось, столь же необъяснимо, как и началось. В эту последнюю перезагрузку из всех изменений лишь добавил профилактический ежечасный apachectl graceful, но очень удивлюсь, если причина в нем - до этого и полная-то перезагрузка апача лишь временно сбивала число открытых файлов, никак не влияя на темп роста kern.openfiles. Фиксирую это на всякий случай, вдруг при мягком рестарте что-то освобождается более аккуратно. Сегодня убрал и его, уровень продолжает держаться в районе 35%.
Ну и раз уж полез в это дело, перетряхнул настройки апача и nginx, причесал конфиги, заменил апачевские SSI на nginx'ные. В процессе переноса выяснилось, что nginx не заморачивается самостоятельной передачей параметров внешнего файла через QUERY_STRING_UNESCAPED в скрипт, вызываемый из SSI, а в качестве REQUEST_URI передает uri скрипта, а не внешнего файла. Пришлось прокидывать правильные значения через дополнительные переменные окружения. Дочистил работу через https - часть внутренних ссылок задавалась через абсолютные url, так что после входа по https через некоторое время можно было обнаружить себя в обычном http. Ну и у админки теперь принудительный редирект на https.
Попытался перенастроить и работу с запароленными каталогами с апачевской на nginx'овую, в итоге отказался от этой идеи. Во-первых, неудобно организовано - нет группового файла, в итоге для разных групп нужно плодить наборы из разных файлов с паролями. Во-вторых, требуется очень своеобразная настройка в конфиге - location с регекспами, как выяснилось, имеют преимущество над фиксированными, поэтому для отдельного location админки приходится включать внутрь дублированный location с маской для пробрасываемых в апач скриптов. Без этого дублирования отдельный location с маской будет первым перехватывать запросы, игнорируя всю авторизацию (и вводя в полнейший ступор настраивающего столь интуитивным поведением). Последней каплей стало то, что в случае неудачной авторизации при последующих соединениях браузер уже не пытается запросить пароль, поскольку сервер начинает постоянно отдавать ему 403 Forbidden вместо ожидаемого 401 Unauthorized. Возможно, это такой побочный эффект включенной limit_req_zone, но разбиратся уже не стал, привычный вариант все равно удобней.
подробно о проекте
Анализ криптографических сетевых...
