Охота на «слишком много файлов» вызывают

Question

Мы попали в странный вопрос на одном из серверов клиентов, где Java сталкивается «Слишком много файлов»,

Проверка дескрипторов с помощью LSOF производит большой список «носка» дескрипторы с «невозможно определить протокол».

Я подозреваю, что это происходит из-за сокетов, которые открывались слишком долго, но поскольку в нашем дампе потока содержится много их, я не знаю, кто именно виновник.

Есть ли хороший способ определить, какие потоки точно открывают эти сокеты?

Спасибо.

Answer 1

Есть ли хороший способ определить, какие нити точно открывают эти сокеты?

Не теги per se.

Один из подходов - запустить приложение с использованием профилировщика. Это может найти проблему, даже если вы не можете точно воспроизвести проблему клиента. (@SyBer сообщает, что YourKit профайлер имеет конкретную поддержку для поиска утечек сокетов ... см комментария.)

Второго подхода заключается в настройках тестовой платформы с помощью ulimit, чтобы уменьшить число открытых файлов, разрешенных. Это может облегчить воспроизведение сценария «слишком много файлов» в тестовой среде.

Наконец, я бы рекомендовал «grepping» ваш код, чтобы найти все места, где создаются объекты сокета. Затем изучите их все, чтобы убедиться, что они правильно используют блоки try/finally, чтобы гарантировать, что сокеты всегда закрыты.

Answer 2

Вы попробовали ulimit, чтобы увеличить количество открытых файлов? Кроме того, возможно, что вы не закрываете свои сокеты должным образом, поэтому у вас есть утечка.

Answer 3

Единственный «хороший» метод обнаружения утечек сокетов - это очень подробный журнал или профилировщик. Сделайте дамп памяти и проанализируйте объекты.

Answer 4

Начинают

netstat -ano | grep $YOUR_PROCESS_ID - для UNIX

netstat -ano | find "$YOUR_PROCESS_ID" - для окон

По крайней мере, вы будете видеть, действительно ли существует связь.

Answer 5

Valgrind будет идентифицировать утечку дескриптора файла, если вы пройдете --track-fds=yes. Valgrind генерирует короткие следы стека в точке «получения» ресурсов, которые он отслеживает. Когда вы находите исходные строки, происходит утечка, вы можете комбинировать это значение с возвращаемым значением pthread_self в вашей системе ведения журнала (я уверен вы бы использовали его!), Или поместите breakpoints в gdb.

Возможно, вы пренебрегаете close() разъемами, с которыми вы закончили. Это необходимо сделать, даже когда сверстник инициирует выключение.