Too many open files Ubuntu 18.04

А я на твой вопрос отвечал

ЛОЛ, дурачка включил? Ну ну.

Соответственно, жестко забито максимальное число открытых файлов 1024

Нет, не жёстко.

Даже если увеличить его в 2-4 раза - это принципиально ничего не изменит!

Изменит, код станет прекрасно работать.

переписывать исходники PHP

PHP тут вообще не при делах, ограничение в libc.

рассмотрены 6 стратегий значительного увеличения числа одновременно открытых соединений

Увеличения относительно чего?

Соответственно, жестко забито максимальное число открытых файлов 1024

Нет, не жёстко.

переписывать исходники PHP

PHP тут вообще не при делах, ограничение в libc.

Протри глаза! Это кто пишет - «You MUST recompile PHP with a larger value of FD_SETSIZE»?

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

Даже если увеличить его в 2-4 раза - это принципиально ничего не изменит!

Изменит, код станет прекрасно работать.

Код и сейчас прекрасно работает - но только до 1024 одновременных соединений. После изменения макс. числа файлов будет «прекрасно» работать до 2048 одновременных входящих и вставать колом при превышении их количества.
Я не могу назвать это «прекрасной» работой, т.к. никогда заренее не известно, сколько пользователей будет ломится на сайт. Достаточно упомянуть ссылку на сайт на ЛОРе и сайт перестанет «прекрасно» работать!

Увеличения относительно чего?

Увеличение относительно тупого использования select с жестко заданным максимумом числа открытых файлов!
Для особо «тупых» напоминаю - проблема называется C10k и рассматриваются методы одновременной обработки 10000 входящих соединений. Проблема С10к была успешно решена 10 лет назад и переросла в проблему С10М. Но неграмотные бараны по прежнему не могут более 1024 соединения!

Это кто пишет - You MUST recompile PHP

никогда заренее не известно, сколько пользователей будет ломится на сайт

ЛОЛ, как это не знаем, 10k. Т.е. проблема 10k решается изменением константы в библиотеке и перекомпиляцией. Так себе проблема, о чём тогда весь сыр-бор.

Увеличение относительно тупого использования select с жестко заданным максимумом числа открытых файлов

Тупое использование select это как раз первый пункт в твоей методичке. Если это решение, то в чём тогда проблема?

Тупое использование select это как раз первый пункт в твоей методичке. Если это решение, то в чём тогда проблема?

Прочитай исходное сообщение автора! В PHP жестко вкомпилировано число 1024. Даже сейчас - в 2022г.!

В методичке С10k приведены все методы решения задачи, в том числе и уже имеющийся select. И там как раз критикуется метода «давайте селекту установим максимум в 10000» - и проблема решена. select - вообще ущербная вещь по дизайну. Поэтому придумали epoll, kqueue, IOCP

В PHP жестко вкомпилировано число 1024

PHP собирается по-умолчанию с таким значением. Никаких теоретических ограничений нет.

там как раз критикуется метода

Критикуется или нет, это возможное решение. Т.е. у ТСа код концептуально адекватный и проблемой 10k не страдает (одобрено даже твоей методичкой). У него проблема с неправильными настройками. Кроме того можно было взять более современный инструмент для мультиплексирования, но это также совершенно другая проблема. С какого хера ты сюда приплёл проблему 10k, в которой ты сам ни ухом ни рылом, я не знаю.

PHP собирается по-умолчанию с таким значением. Никаких теоретических ограничений нет.

Если нет ограничений - поставь 1M и продемонстрируй, что все не правы! Что у select нет «теоретических ограничений»

Критикуется или нет, это возможное решение. Т.е. у ТСа код концептуально адекватный и проблемой 10k не страдает (одобрено даже твоей методичкой). У него проблема с неправильными настройками.

Ты же предлагал ТС переписать код на epoll?

В методичке С10к разбирается, почему select c FD_SETSIZE=10000 это очень плохо! Ты же сам предлагал «отказаться от select и использовать epoll» - теперь предлагаешь просто увеличить константу максимума. Если все было так просто с select, то зачем «дебилы» придумали сначала poll, затем epoll на замену select?

Ты глазки то протер? Или будешь по прежнему нести бред «это не в PHP ограничения, а в системе»

почему select c FD_SETSIZE=10000 это очень плохо!

Это не очень плохо. Более того, когда не было epoll так и делали.

Если все было так просто с select, то зачем «дебилы» придумали сначала poll, затем epoll на замену select?

Потому что могли, ваш К.О. Выбор между select и epoll это выбор между хорошей и очень хорошей реализацией одного и того же принципа.

что все не правы

Кто все? Только ты тут усрался доказывать что у ТСа проблема 10k.

это не в PHP ограничения, а в системе

Конечно не в PHP. Когда это select стал частью PHP, а не системы?

это не в PHP ограничения, а в системе

Конечно не в PHP. Когда это select стал частью PHP, а не системы?

Когда же ты свои глаза протрешь?

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

Эти сообщения пошли от PHP, когда ТС увеличил лимит открытых файлов для конкретной программы более 1024 (как было по умолчанию). Т.е. в системе нет ограничения на 1024, а в PHP есть! Эти ограничения именно в РНР!!! И лечатся перекомпиляцией РНР, а не системы! Автор прикладной программы создает и инициализирует структуры, вычисляет максимально возможный номер файлового дескриптора и передает это все в select(). Вот у ТС и получилось, что структуры созданы под 1024 дескриптора, а дескриптор имеет номер 1126!!! И его никак не обработать, даже если всего дискрипторов мало.

Еще раз - для тупых баранов - это ограничение прописано в РНР, несмотря на возможности системы обрабатывать больше.
Другая программа, используя тот-же системный select будет обрабатывать одновременно больше файлов, не затыкаясь на 1024.

Выбор между select и epoll это выбор между хорошей и очень хорошей реализацией одного и того же принципа.

Только тупые неграмотные бараны могут назвать select «хорошей реализацией одного и того же принципа».
У select() есть сразу несколько существенных недостатков:

• select модифицирует передаваемые ему структуры fd_sets, так что ни одну из них нельзя переиспользовать. Даже если вам не нужно ничего менять (например, получив порцию данных, вы хотите получить ещё) структуры fd_sets придётся переинициализировать. Ну или копировать из заранее сохранённого бэкапа с помощью FD_COPY. И это придётся делать снова и снова, перед каждым вызовом select.
• для выяснения того, какой именно дескриптор сгенерировал событие, придётся вручную опросить их все с помощью FD_ISSET. Когда вы мониторите 10000 дескрипторов, а событие произошло лишь для одного из них (который по закону подлости будет последним в списке) — вы потратите уйму процессорных ресурсов впустую.
• Вы не можете работать с дескрипторами из наблюдаемого набора из другого потока.
• select накладывает на вас бремя вычисления «наибольшего дескриптора» и передачу его отдельным параметром

В то время как epoll вообще не имеет ограничений количества дескрипторов и возвращает количество и структуры событий только для дескрипторов, изменивших состояние.

PS: мне тут тараканы нашептали, что select «так хорош», что его вообще выкинули из ядра, и теперь select - это обертка для poll

Эти сообщения пошли от PHP

А должны были с Луны поступать? Если в PHP поделить на ноль, виноват тоже будет PHP?

это ограничение прописано в РНР

Это ограничение прописано в /usr/include/bits/typesizes.h. Каким боком системные константы относятся к PHP? При компиляции какое-то значение константы должно быть, пых берёт системный дефолт, если не указано иное.

сразу несколько существенных недостатков

И что? Перебирать 10k дескрипторов всё равно в 100500 раз быстрее чем переключать 10k процессов. По сравнению с действительно проблемным кодом это всё ни о чём.

Эти сообщения пошли от PHP

А должны были с Луны поступать? Если в PHP поделить на ноль, виноват тоже будет PHP?

Конечно - РНР! Если вы написали код и он вызывает ошибки - виноват написанный код, а не система! Удобная у вас позиция - позволяет любые ошибки в говно-коде списать на систему. Это не я - это система виновата.
К сожалению, мне приходится свои ошибки находить и исправлять, на систему свалить не удастся!

Перебирать 10k дескрипторов всё равно в 100500 раз быстрее чем переключать 10k процессов.

А кто предлагает «переключать 10k процессов»? Опять тараканы в вашей голове нашептали? select появился в 4.2bsd примерно в 1983г. В Линуксе существовал с самых первых версий. Apache в те времена запускал пул процессов-обработчиков, каждый из которых обрабатывал до 1024 входящих. Т.е. сколько тысяч входящих хотел обработать - столько обработчиков прописывал в конфиге. Мне всегда 1-го процесса хватало - никогда 1000 одновременных соединений не было.