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

[Igor Sysoev]

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


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