Переполнение логов

Volkov Oleg volkov at teratelecom.ru
Tue May 20 14:48:57 MSD 2008


В сообщении от Tuesday 20 May 2008 12:46:52 Igor Sysoev написал(а):
> On Tue, May 20, 2008 at 12:32:43PM +0400, Volkov Oleg wrote:
> > Сегодня nginx переполнил мне весь /var сообщениями в
> > какой-нибудь-сайт-errors_log :
> >
> > 2008/05/20 11:57:07 [alert] 28859#0: accept() failed (24: Too many open
> > files) while accepting new connection on 0.0.0.0:80
> >
> > Соответственно увеличил worker_connections  в 10 раз, пока вроде
> > нормально. events {
> >         worker_connections  81920;
> >         use epoll;
> > }
> >
> > Этого достаточно?
>
> Нет. Нужно увеличивать число файлов, выделенных процессу и в целом в
> системе.

А в linux это где ? Что-то пока не нашел.

# cat /proc/sys/fs/file-max 
204140
# cat /proc/sys/fs/file-nr 
3584	0	204140

Число воркеров у меня 20. Если я правильно понимаю - у меня именно внутреннее 
ограничение worker_connections  сработало.

И еще, можно сделать чтобы по логам нгинкса было ясно как ограничитель 
сработал (внутренний или внешний) ?

> > Еще есть вопрос, нельзя ли как-нибудь изменить систему логов чтобы они не
> > разпухали с одинаковыми сообщениями (например написать что данное
> > сообщение повторено N раз) если строчки полностью совпадают (включая
> > время в секундах) ?
>
> Пока нет.

А с чем это связано? 

Дело в том, что при нормальных условиях работы таких проблем не возникает. Это 
была DOS атака, которая и увенчалась успехом именно из-за гигансткого размера 
логов.

Можно сделать патчик чтобы конкретно данное сообщение не выдавалось больше чем 
Х раз в секунду или еще как нибудь, вот небольшой кусочек статистики:

# for A in `tail -100000  test-error_log|  sort -u | awk '{print $2}'` ; do 
echo -n $A ' ' ;tail -100000  test-error_log| grep $A| wc -l ; done
10:17:00  340
10:17:01  9087
10:17:04  1164
10:17:09  5003
10:17:16  11940
10:17:17  22139
10:17:17  22139
10:17:21  2447
10:17:36  2029
10:17:53  11573
10:17:54  7339
10:18:06  7132
10:18:07  19807

-- 
С уважением,
Волков Олег.





More information about the nginx-ru mailing list