Читайте внимательнее -- "leacky bucket" как раз придерживает соединение в некоторой очереди, пока не будут обработаны другие соединения для этого сайта. К этому же ведёт ограничение на процент процессора -- вместо того, чтобы бросить все ресурсы сервера на обработку, соединения одного пользователя будут копиться, лишая других пользователей других ресурсов (например, память, io (так как, возможно, чем дольше будет выполняться процесс, тем чаще его данные будут вымещаться из дискового кеша, тем чаще ему придётся лезть за ними на диск)).
Маркетинг-не маркетинг, а почти все пользователи CL, которых я знаю, пользуются им из-за этого.
Т.е. перекидывать запросы между процессами апача?
Каким образом 2 и 3 могут точно это проверить?
Это не имеет смысла -- создание одного узкого места искуственно ведёт к проблемам в других местах. Например, если мы настроим для виртхоста обработку запросов через leacky bucket, то у нас может переполниться backlog. То же самое и с другими ресурсами.
Поэтому сейчас они исследуют новую возможность -- выставлять большие лимиты и запускать специальный демон, который будет следить за потреблением ресурсов и применять санкции к пользователям, которые потребляют слишком много. Напоминает парсинг bsd accounting, да? :)
Нано актуально только в России, а cloud -- везде.
На самом деле весь пук заключается в том, что это готовое, поддерживаемое и относительно работающее решение.
mod_cgroup не изучал подробно, но беглый взгляд на исходники говорит, что процесс совсем легко может выйти из своей группы. CloudLinux в этом месте хотя бы требует секретную uint32_t cookie, и при неверном её указании убивает процесс.
Тут как раз идеи из горячо обсуждаемого mpm-itk подойдут -- не давать процессу покинуть cgroup, а только умереть, но это большая дыра в производительности.
... для этого нужна новая операционная система! 🤪 (cloudlinux)
Это хорошая идея. Попробуйте через kpartx примонтировать образы виртуалок к ноде и провести такую же проверку.
Да, приношу извинения. Как только в теме начался обычный процесс выяснения, кто квалифицированее, я стал читать её по диагонали и не заметил целых три сообщения, касающихся проблемы топикстартера :)
Да нет, местные админы никогда бы не упустили шанс поопускать друг друга ;)
Намного интереснее то, что все системные администраторы спалились в своём полном непонимании работы TCP-стека -- уже во втором сообщении топика фатальная ошибка, а на неё даже никто не указал.
Нет, там 16.
[root@CentOS-60-64-minimal ~]# cat /proc/sys/vm/zone_reclaim_mode
0
У Вас материнки какие-то не такие :)
