Too many open files Ubuntu 18.04

PhpStorm / IDEA ?

Что вернет ulimit -Hn?

Куда копать?

Не куда, а где - на SO.

Проверь cat /proc/sys/fs/file-max

Мало, у меня так:

$ sudo /sbin/sysctl fs.file-max
fs.file-max = 9223372036854775807

Не помогло, после перезапуска сервера сокетов доходит до определенного количества соединений и падает:

Jul 11 20:45:21 ws php[677]: 2022-07-11 20:45:21: server_call 192.168.0.31 (102) has connected.
Jul 11 20:45:21 ws php[677]: 2022-07-11 20:45:21: server_call 192.168.0.31 (514) has connected.
Jul 11 20:45:21 ws php[677]: 2022-07-11 20:45:21: server_call 192.168.0.31 (514) has disconnected.
Jul 11 20:45:21 ws php[677]: 2022-07-11 20:45:21: server_call 192.168.0.31 (516) has connected.
Jul 11 20:45:21 ws php[677]: 2022-07-11 20:45:21: server_call 192.168.0.31 (516) has message.
Jul 11 20:45:30 ws systemd-timesyncd[334]: Synchronized to time server 185.125.190.57:123 (ntp.ubuntu.com).
Jul 11 20:45:32 ws php[718]: PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139
Jul 11 20:45:44 ws php[718]: message repeated 464 times: [ PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139]
Jul 11 20:45:44 ws php[677]: PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139
Jul 11 20:45:44 ws php[718]: PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139
Jul 11 20:45:44 ws php[718]: PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139
Jul 11 20:45:44 ws php[677]: PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139
Jul 11 20:45:44 ws php[718]: PHP Warning:  socket_accept(): unable to accept incoming connection [24]: Too many open files in /home/admin/web/classes/class.PHPWebSocket.php on line 139

Поищи в конфигах PHP настройку rlimit_files. Возможно, у тебя ещё и там ограничение стоит.

rlimit_files в PHP-FPM, у меня он не используется. Создан сервис через systemd, PHP запускается так: ExecStart=/usr/bin/php -f server_call.php &

Покажи весь файл unit-а systemd. Запусти через этот же файл ulimit, возможно там другие ограничения, а не те, что ты показываешь при запуске из под рута в терминале

Вы оказались правы, из под systemd команда ulimit -n возвращает 1024

Как указать для него другое значение?

https://www.freedesktop.org/software/systemd/man/systemd.exec.html limitNOFile

Печаль, без перекомпиляции никак?

LimitNOFILE=65536

Jul 11 21:48:00 ws php[5734]: Warning: socket_select(): You MUST recompile PHP with a larger value of FD_SETSIZE. Jul 11 21:48:00 ws php[5734]: It is set to 1024, but you have descriptors numbered at least as high as 1126. Jul 11 21:48:00 ws php[5734]: –enable-fd-setsize=2048 is recommended, but you may want to set it Jul 11 21:48:00 ws php[5734]: to equal the maximum number of open files supported by your system, Jul 11 21:48:00 ws php[5734]: in order to avoid seeing this error again at a later date. in /home/admin/web/classes/class.PHPWebSocket.php on line 110

Эм, ты там открываешь более 1024 соединений? Не могу сказать, не делал такого)

Да, этот сервер обрабатывает websocket подключения. Похоже придется переписывать на python

Может поможет просто установка PHP из какой-то другой репы

Похоже придется переписывать на python

php-fpm + rlimit_files не поможет, разве?

бинго

перекомпилить проще

А если отредактировать /etc/systemd/system.conf?

DefaultLimitNOFILE=1024:524288

поменять на

DefaultLimitNOFILE=4096:524288

А если с другого конца зайти и стартовать несколько процессов php, разделяющих сокет через какой-нибудь SO_REUSEADDR?

Просто пых видимо не очень из коробки предназначен на один процесс обрабатывать тысячи соединений.

Ну, или расчехлять как-то fpm

Так ошибку уже сам PHP выдаёт, а не система. Мол, не предназначен я с текущими опциями сборки разгребать в одном процессе столько всего.

ошибку уже сам PHP выдаёт, а не система

Вообще-то система. А конкретно это ограничения для select, которое определено в /usr/include/bits/typesizes.h. Нужно использовать epoll, а не select.

Похоже придется переписывать на python

Ору.

Куда копать?

Читать теорию! Это же классическая «проблема 10000 соединений» C10k. Разбиралась лет 10 назад. Например почитай - https://russianblogs.com/article/9837637595/

Читать теорию

Тебе б самому что-нибудь почитать, можно журнал «Мурзилка». Проблема ТСа никакого отношения к 10k не имеет.

Проблема ТСа никакого отношения к 10k не имеет.

Мы должны поверить тебе на слово? Или как то обоснуешь? Критикуешь - предлагай!
Ты сам похоже только «Мурзилку» способен осознать.
Это именно она - проблема С10к - ограничение числа открытых файлов для одного процесса.
И поднятие лимита открытых файлов с 1024 до 4096 ничего принципиально не решает!

Мальчик, ты дурак? Я уже всё рассказал, почему так и что делать.

проблема С10к - ограничение числа открытых файлов для одного процесса

Нет, это совершенно другая проблема.

Похоже придется переписывать на python

И это хорошо, минус один проект на убогоньком PHP, плюс один проект который люди смогут поддерживать дальше.

Нужно было сразу так.

минус один проект на убогоньком PHP

Минус один убогонький проект на PHP. Плюс один на питоне.

/fixed

почитай - https://russianblogs.com/article/9837637595/

Какой-то «понос словаря» по ссылке. Это же автоматический перевод, который никто не удосужился вычитать и отредактировать.

Это же классическая «проблема 10000 соединений» C10k

Нет, потому что в сообщениях об ошибках чуть выше по треду упоминается select, то есть соединения уже обрабатываются по много штук в одном потоке. Проблема c10k была связана с тем, что самый используемый тогда веб-сервер Apache умел работать только в блокирующем режиме, запуская по процессу на каждое соединение. Процессы дорогие в терминах потребляемого процессорного времени и объёма ОЗУ. Тут же, скорее всего, всего один процесс с одной нитью.

например, максимум выбора не может превышать 1024

Это из текста по ссылке. Скорее всего, там имелся в виду вызов select(). В libc действительно есть лимит на размер битовых карт. Но вообще в ядре Linux ограничения на размер карт нет. По крайней мере, я ограничений не увидел. Там предполагается, что если kvmalloc() успешно выделил достаточный объём под все шесть карт (три на вход и три на выход), то всё нормально.

Другое дело, что не имеет смысла оставаться на select(), когда число соединений исчисляется тысячами.

Мальчик, ты дурак? Я уже всё рассказал, почему так и что делать.

Тупой малолетний читатель мурзилки! Ты именно процитировал один из методов решения проблемы С10К - переход от select к epull.

один из методов решения проблемы С10К - переход от select к epull

Тебе уже 2 раза сказали, что 10k это вообще про другое. 10k возникало не из-за каких-то лимитов, а концептуально из-за накладных расходов на fork. Где ты тут увидел fork дурачина? Ну или хотя бы какие-то другие тормоза из-за архитектуры (если уж толковать 10k в широком смысле)? Иди делай уроки читай, что там на лето задали, не позорься.

Какой-то «понос словаря» по ссылке. Это же автоматический перевод, который никто не удосужился вычитать и отредактировать.

Согласен - это первый попавшийся перевод. Можно почитать оригинал - http://www.kegel.com/c10k.html

Нет, потому что в сообщениях об ошибках чуть выше по треду упоминается select, то есть соединения уже обрабатываются по много штук в одном потоке.

Прочитай же первоисточник! А то не читал - но осуждаю! Там в самом начале обсуждаются недостатки select() при использовании неблокирующих вызовов для обработки одним процессом множества входящих соединений. Уже тогда апач запускал пул процессов, каждый из которых мог обрабатывать несколько входящих соединений. Именно тогда (примерно 2000-2001г.) в ядре появился epull

Тебе уже 2 раза сказали, что 10k это вообще про другое.

Я больше верю первоисточнику - ссылку я тебе дал! Там в самом начале обсуждаются методы обработки одним процессом множества входящих соединений. Неблокирующий ввод-вывод через select, epull, kqueue и т.п. Асинхронный ввод-вывод.
Из 6 рассмотренных стратегий - 3 посвещены именно обработке множества соединений в одном потоке.
И только потом переходят к обсуждению легковесных потоков для обработки входящих. Из 6 стратегий - только одна про много-поток!
Далее идет тяжелая артиллерия - перенос обработки в ядро или использования сетевого стека из пространства пользователя.

Где ты тут увидел fork дурачина?

Дурачок - прочитай наконец статью c10k - http://www.kegel.com/c10k.html
Вот ее содержание:

1. Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification
2. Serve many clients with each thread, and use nonblocking I/O and readiness change notification
3. Serve many clients with each server thread, and use asynchronous I/O
4. serve one client with each server thread, and use blocking I/O
5. Build the server code into the kernel

Где тут про fork - тупая дурачина?
Ученье - свет! Использование вышеприведенных стратегий ввода-вывода позволяет перейти от проблемы С10К к проблеме С10М.

Да, этот сервер обрабатывает websocket подключения. Похоже придется переписывать на python

Сам по себе python ничего не изменит! В нем точно также можно написать сервер на блокирующемся вводе-выводе (если не использовать что-то типа Торнадо).

Попробуй https://github.com/kakserpom/phpdaemon - asynchronous server-side framework of network applications implemented in PHP using famous libevent which makes possible to handle thousands of simultaneous connections.
Вот пример - https://hharek.ru/веб-сокет-сервер-на-phpdaemon

Я кажется понял, ты один из тех дебилов, кто думает что проблема 10k это как сделать сервер на 10k соединений. Хотя это никогда не было проблемой.

точно также можно написать сервер на блокирующемся вводе-выводе

У ТСа асинхронный IO, дубина.

Я кажется понял, ты один из тех дебилов, кто думает что проблема 10k это как сделать сервер на 10k соединений. Хотя это никогда не было проблемой.

Дурачок - читай литературу! Ученье - свет! Срочно пиши в Википедию, что они ничего не понимают -
https://ru.wikipedia.org/wiki/C10k
C10k (англ. C10k; 10k connections — проблема 10 тысяч соединений) — условное название задачи конфигурирования и обслуживания высокопроизводительного сервера, способного обслуживать порядка 10 тыс. соединений одновременно.

И только тараканы в твоей голове знают истину!

У ТСа асинхронный IO, дубина.

Тупое бревно! Перестань позориться - у автора нет асинхронного IO. В лучшем случае - неблокирующийся.

Ну если для тебя асинхронное это когда есть слово async (потому что так в мурзилке пишут), то можешь считать что нету. А так-то вообще есть конечно.

они ничего не понимают

Не ты ли ту статью написал? Давай так, если у ТСа проблема 10k, то в чём конкретно его ошибка?

Не ты ли ту статью написал?

Если ты считаешь, что там написано неправильно - срочно вноси правку. И в английскую - https://en.wikipedia.org/wiki/C10k_problem тоже я написал?

По твоему - вокруг одни дебилы, и только ты - гений?

вокруг одни дебилы

Нет только ты. На вопрос ответишь?

Нет только ты. На вопрос ответишь?

А я на твой вопрос отвечал - «Не ты ли ту статью написал?»

Я кажется понял, ты один из тех дебилов, кто думает что проблема 10k это как сделать сервер на 10k соединений. Хотя это никогда не было проблемой.

Это была проблема в 1999-2001г. Для решения этой проблемы придумали kqueue во Фре, epoll в Линуксе, IOCP в Винде. Потом проблема С10k плавно перешла в проблему C10М.

Все, кроме тебя, признают что была проблема С10k и она именно «как сделать сервер на 10k соединений». Читай первоисточники - они рулез!

Прочитай же первоисточник! А то не читал - но осуждаю!

Ты лучше внятно изъяснись вместо попыток прикрыться громкими названиями.

У автора вопроса используется мультиплексирование ввода через select

ws php[5734]: Warning: socket_select(): You MUST recompile PHP with a larger value of FD_SETSIZE. Jul 11 21:48:00 ws php[5734]: It is set to 1024, but you have descriptors numbered at least as high as 1126. Jul 11 21:48:00 ws php[5734]: –enable-fd-setsize=2048 is recommended

Соответственно, жестко забито максимальное число открытых файлов 1024. Даже если увеличить его в 2-4 раза - это принципиально ничего не изменит! В классической работе http://www.kegel.com/c10k.html рассмотрены 6 стратегий значительного увеличения числа одновременно открытых соединений:

• Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification
• Serve many clients with each thread, and use nonblocking I/O and readiness change notification
• Serve many clients with each thread, and use asynchronous I/O
• Serve one client with each server thread, and use blocking I/O
• Build the server code into the kernel
• Bring the TCP stack into userspace

Поскольку автор вопроса явно не собирается переписывать исходники PHP, заменяя select на epool - ему было предложено использовать асинхронный фреймворк https://github.com/kakserpom/phpdaemon

жестко забито максимальное число открытых файлов 1024. Даже если увеличить его в 2-4 раза - это принципиально ничего не изменит!

Если автору нужно где-то 1500 соединений, увеличение лимита до 2048 даст принципиально изменение. Система из состояния «не справляется» перейдёт в состояние «справляется». Весьма сильное изменение.

ему было предложено использовать асинхронный фреймворк

Посмотри внимательно на заглавное сообщение. Оно не похоже вопрос от автора кода. Люди, которые код сами пишут, прекрасно понимают, что «on line 139» не говорит ровным счётом ничего, если код никто не видит. А это значит, что автор вопроса не сможет переписать код. Но вот перекомпилить PHP в принципе возможно и без особых знаний.

В debian это было в /etc/security/limits.conf, может в убунте тоже?