Утечка файл дескрипторов?

[Igor Sysoev]

On Tue, 15 Mar 2005, Igor Sysoev wrote:

> On Tue, 15 Mar 2005, Mike Kolesnikov wrote:
>
>> Igor Sysoev wrote:
>> 
>>>> cat /proc/sys/fs/file-nr
>>>> 1993    113     104032
>>>> 
>>>> Рестарт nginx помогает, дескрипторы освобождаются:
>>>> cat /proc/sys/fs/file-nr
>>>> 1993    1095    104032
>>>> 
>>>> После получаса работы имеем:
>>>> cat /proc/sys/fs/file-nr
>>>> 1993    961     104032
>>> 
>>> 
>>> Если я правильно понимаю в Линуксе, то эти строки показывают следующее:
>>> 
>>> 1) за всё время было открыто одновременно всего 1993 файла;
>>> 2) в первом примере открыто 113 файла;
>>> 3) после рестарта стало открыто 1095; где здесь происходит освобождение,
>>>     я не вижу;
>> 
>> Нелогично, правда? Выходит, после рестарта сразу 900 дескрипторов были
>> резко запользованы неизвестно кем?
>> 
>>> 4) после получаса работы открыто 961 файл, то есть, меньше, чем на старте.
>> 
>> Опять нелогично. Проблему усугубляет то, что Documentation/sysctl/fs.txt
>> в ядрах 2.4 и 2.6 утверждает по поводу второго значения file-nr
>> совершенно противоположные вещи. Вот из 2.6:
>> "The three values in file-nr denote the number of allocated
>> file handles, the number of unused file handles and the maximum
>> number of file handles."
>> В 2.4 вместо unused file handles стоит used file handles.
>> 
>> В еще одном месте нашел вот такую визуальную репрезентацию:
>> [root at pixie proc]# cat /proc/sys/fs/file-nr
>> 3391    969     52427
>> |	 |       |
>> |	 |       |
>> |        |       maximum open file descriptors
>> |        total free allocated file descriptors
>> total allocated file descriptors
>> (the number of file descriptors allocated since boot)
>> 
>> Но судя по реальному опыту, ближе к истине все же документация версия
>> 2.6. (правда, на всех доступных машинах с ядром 2.6 второе значение
>> всегда равно нулю...). Тем не менее на серверах с ядром 2.4 второе
>> значение file-nr весьма хорошо коррелирует с документацией 2.6, т.е.
>> прибиваешь какой-нибудь апач - оно увеличивается, запускаешь снова -
>> уменьшается.
>> 
>>> Скорее всего, нужно увеличить "limits -n".
>>> Можно ещё отключить keep-alive, если он не нужен:
>>> 
>>> keepalive_timeout  0;
>> 
>> Дык keep-alive хотелось бы оставить. Лимит попробую увеличить, но боюсь
>> это лечение симптомов.
>> Сейчас кстати кол-во свободных дескрипторов устаканилось:
>> cat /proc/sys/fs/file-nr
>> 1993    969     104032
>> Я буду следить за ситуацией, lsof и /proc/<pid>/fd нам помогут :)
>
> Да, судя по всему, второе поле означает число свободных file handles
> из тех что уже были выделены (первое число). Я просто тыкнул в две ссылки
> в Гугле и прочитал про unused. Но в любом случае, в системе не

Вернее, не "про unused", а "про used".

> использовалось одновременно больше 1993 файлов. Стало быть, это не утечка,
> а limit. А что показывает nginx при запуске в самом начале про
> getrlimit(RLIMIT_NOFILE) ?


Игорь Сысоев
http://sysoev.ru