информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Сетевые кракеры и правда о деле ЛевинаПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Sophos открывает Sandboxie 
 Большой вторник патчей от MS 
 И ещё раз об интернет-голосовании 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / блог / архив / 2015
АРХИВ
архив
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
archive





сервернотекучее
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, но разбиратся уже не стал, привычный вариант все равно удобней.

   
теги: софт  |  обсудить  |  все отзывы (0)  |  обсудить в LJ [1415]
назад «  » вперед

аналогичные материалы
сиктранзитное // 19.12.18 20:27
OpenVPNское // 27.08.18 15:09
креаторскобожественное // 20.05.17 16:37
креаторскобэкапное // 08.04.17 19:07
глухояндекснонавигаторное // 16.02.17 17:53
летсэнкриптное // 28.09.16 17:59
фримиумноненавистное // 26.09.16 18:40
аутентификационное // 25.08.16 02:23
навигаторское // 24.08.16 18:30
беспунтовое // 19.06.16 15:59
 
последние записи
мтснороуминговое // 11.09.19 12:35
бунтороботное // 11.07.19 22:17
асусноапгрейдное // 23.06.19 22:29
айпаднофлешное // 17.06.19 21:39
отпускное // 09.06.19 22:12
берлинскоавтобусное // 29.05.19 19:57
онлайноголосовальное // 29.05.19 14:35
геймофтронное // 18.05.19 17:54
бироуминговое // 15.05.19 19:02
регистрационнонервное // 08.05.19 00:41


авто венгрия вырвиглаз германия глюки греция гуглемап драйверы египет железки журнализм империя добра испания италия кино кипр клоуны книги криворучки оспорт португалия программизм сайт софт стрим студень турция уродцы фото франция цацки чехия читалки android bq e51 eeepc from facebook hd2 hpc htc ipad iphone onlime vista windows 10 windows 7 windows 8 yota



Rambler's Top100
Рейтинг@Mail.ru



  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach