Охота на «слишком много файлов» причина

Question

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

Проверка дескрипторов с помощью lsof приводит к большому списку дескрипторов «sock» с «не может идентифицировать протокол».

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

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

Спасибо.

Answer 1

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

Не потоки как таковые .

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

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

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

Answer 2

Начните с

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

netstat -ano | find "$YOUR_PROCESS_ID" - для windows

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

Answer 3

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

Answer 4

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

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

Answer 5

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