Ограничивает ли команда ulimit то, что отображатеся командой lsof ?

У меня появилась проблема с Glassfish (это сервер приложений Java).
При запуске он пишет:

java.io.IOException: Too many open files

Я почитал форумы и нашёл эти две команды.

Командой ulimit -n 65000, как я понимаю, я задал верхнюю границу числа открытых потоков.
Команда lsof должна выдать список всех открытых потоков в данный момент. Чтобы посчитать их, я должен направить результат в команду wc -l, таким образом lsof | wc -l, как я ожидал, покажет число открытых потоков в данный момент.


Проблема не исчезла, команда lsof | wc -l даёт число намного меньшее, чем 65000.

Может я неправильно трактую эти команды ?

Ругается-то JVM, не туда копаешь, мне так кажется...

mycetophylax написал:

Ругается-то JVM

Она ругается из-за ошибок, возникающих в ОС. Понятно, что возможно виновата не ОС, а сервер. Но чтобы локализировать ошибку, мне нужно знать, как можно через команды ОС узнать, что не так делает сервер. Возможно в ОС есть какая-то настройка, которая мешает серверу.

boraldo написал:

[quote=mycetophylax]Ругается-то JVM

Она ругается из-за ошибок, возникающих в ОС. Понятно, что возможно виновата не ОС, а сервер. Но чтобы локализировать ошибку, мне нужно знать, как можно через команды ОС узнать, что не так делает сервер. Возможно в ОС есть какая-то настройка, которая мешает серверу.[/quote]
У тебя это происходит при старте сервера, т.е. число подключенных к нему клиентов в этом момент не такое уж и большое (т.е. вообще никакое :D ), стандартных ОСовских настроек должно хватать, сервер ведь вообще без нагрузки.
Ковырять надо либо настройки самого Glassfish'а (хотя я в этом сомневаюсь), либо что-то не то с приложением (ями) (вот это более вероятно), которое на нем крутится. Утечка идет где-то там! А менять параметры системы из-за того, что сервер не работает в "холостом режиме" это... А что тогда будет под нагрузкой?

mycetophylax написал:

Ковырять надо либо настройки самого Glassfish'а (хотя я в этом сомневаюсь), либо что-то не то с приложением (ями) (вот это более вероятно), которое на нем крутится.

Всё тоже самое на другой машине работает безотказно.

I have experienced this problem with another Java application running on Debian, it went away when we downgraded to Java version 1.6.0.0. Java never closed unused connections, causing it to throw the exception.