Сокет принимает - “Слишком много открытых файлов”
Вы также можете использовать @Digits из API-интерфейса валидатора гибернации, который реализует стандарт проверки bean-компонентов javax.validation
@Digits(integer = 10 /*precision*/, fraction = 2 /*scale*/)
Из Javadocs
Аннотированный элемент должен быть число в допустимом диапазоне. Поддерживаемые типы:
- BigDecimal
- BigInteger
- CharSequence
- BigInteger
- байт, короткий, int, long и их соответствующие типы упаковщиков
нулевые элементы считаются действительными
4 ответа
Есть несколько мест, где Linux может иметь ограничения на количество файловых дескрипторов, которые вам разрешено открывать.
Вы можете проверить следующее:
cat /proc/sys/fs/file-max
Это даст вам общесистемные ограничения файловых дескрипторов.
На уровне оболочки это сообщит вам ваш личный лимит:
ulimit -n
Это можно изменить в /etc/security/limits.conf - это параметр nofile.
Однако, если вы правильно закрываете сокеты, вы не должны получать его, если не открываете много одновременных подключений. Похоже, что-то мешает правильному закрытию ваших сокетов. Я хотел бы убедиться, что с ними обращаются должным образом.
может пройти немного времени, прежде чем закрытый сокет действительно освободится
lsof для вывода списка открытых файлов
cat / proc / sys / fs / file-max , чтобы узнать, есть ли системный предел
Когда ваша программа имеет больше открытых дескрипторов, чем открытых файлов ulimit (ulimit -a перечислит это), ядро откажется открывать какие-либо другие дескрипторы файлов. Убедитесь, что у вас нет утечек файлового дескриптора - например, запустив его на некоторое время, а затем остановив и проверив, открыты ли еще какие-либо дополнительные fds, когда он простаивает - и если это все еще проблема, измените nofile ulimit для вашего пользователь в /etc/security/limits.conf
TCP имеет функцию под названием "TIME_WAIT", которая обеспечивает чистое закрытие соединений. Она требует, чтобы один конец соединения оставался в режиме прослушивания некоторое время после закрытия сокета.
В высокопроизводительном сервере важно, чтобы именно клиенты переходили в режим TIME_WAIT, а не сервер. Клиенты могут позволить себе иметь открытый порт, в то время как загруженный сервер может быстро исчерпать порты или иметь слишком много открытых FD.
Чтобы достичь этого, сервер никогда не должен закрывать соединение первым - он всегда должен ждать, пока клиент его закроет.