Мониторинг CloudLinyx на шареде

Неужели LSAPI затратнее в поддержке чем другие модули?

И чем же?

Чёй-то? В проблемных запросах не видно название базы?

Наверное, придётся пояснить, почему FPM не всегда быстрее prefork/itk. Дело в том, что в случае FPM запускается враппер и держит на готове запущенные копии интерпретатора PHP. То же самое, в общем, делает и Prefork/itk с той лишь разницей, что оно запущено уже непосредственно в процессах апача в виде модуля. Nginx быстрее апача только в некоторых сценариях и опять же, в хайлоаде это нужно обычно (всё же апач универсальнее). Когда ресурсов хватает - разница на глаз незаметна.

lonelywoolf, да в легенды "Nginx быстрее апача" я не верю :). Я прекрасно понимаю что всё зависит от конкретных условий и использования. И ещё прекрасно понимаю, что Nginx без апача на шареде - это ахтунг для юзеров.

Но это никак не отвечает на мои вопросы.

Тем, что мейнтейнить его и ставить в систему придётся самому, а в CL это сделали за меня. Но я жадный и не хочу платить за CL (тем более, что у меня свой взгляд на вещи). Соответственно, это уже менее стандартная конфигурация.

Ну вот давайте смоделируем.

Есть какой-то сайт, он дергает базу постоянно, и от этого она много думает. Но сами по себе запросы выполняются быстро, вызывая только нагрузку на CPU. Когда таких запросов много (возможности CPU исчерпываются) - сервер БД начинает их выполнять медленнее все. И те, которые были бы при нормальных условиях выполнены быстро, при нагрузке начинают валитсья в лог медленных запросов, даже если они не виноваты в этой нагрузке.

Рассмотрим другой пример. Какой-то пользователь постоянно получает из БД данные, и эти данные кэшируются в кэше MySQL (хотя при большом трафике кэш обычно выключают, но не всегда). В результате повышения нагрузки на сервер БД админ лезет смотреть лог медленных запросов и туда попадают не те, которые создают нагрузку, а те, которые просто время от времени выполняются и вымываются из кэша.

Можно придумать много таких сценариев, где не шибко компетентные хостеры садятся в лужу именно на подобных ошибках. Т.е. я веду к тому, что если запрос выполняется медленно - не значит, что виноват именно этот запрос (в условиях, когда сервер БД нагружен большим количеством пользователей на базах с разной частотой использования и разной структурой). Поэтому часто предпочитают ограничивать именно частоту и длительность запросов вместо того, чтобы разбираться. Агава, например, этим грешит.

---------- Добавлено 20.07.2019 в 01:04 ----------

Я даже больше скажу: иногда Nginx даже вреден. Его обычно используют, чтобы сэкономить память на отдаче статики: ему не нужно в каждом процессе держать интерпретатор PHP со всеми его модулями, поэтому апач занимается обработкой PHP и не грузит на отдачу каждой картинки всё своё барахло, только когда оно нужно. Но ещё Nginx может испортить картину, отдав картинку напрямую, даже если в .htaccess выставить Deny (от так бывает в некоторых конфигурациях).

Хм.. Ну другие-то модули php и апача для др ОС всё равно надо ставить.

И это же разовая операция.

Или я что-то не понимаю?

Ну смоделировали.. В запросах (в логах точнее) есть и база и время выполнения и др данные.

В чем же проблема опознать виновника?

SeVlad, Ну почему же. Что-то делает за нас ISPSystem, а что-то делают сборщики дистрибутива ОС. И уж RedHat (на котором базируется CentOS) как правило, ребятки поумнее большинства среднестатистических админов и вряд ли накосячат там, где накосячит по ошибке/неопытности/невнимательности обычный среднестатистический админ. Я вот, к примеру, хоть и считаю себя серьёзным специалистом, но звёзд с неба не хватаю и явно могу ошибиться с бОльшей вероятностью при сборке этого софта. Или могу не учесть какие-то мелкие нюансы, которые могут проявиться при очередном обновлении софта.

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

Хорошо. У нас сервер БД выполняет 20-50к запросов в секунду (!). Объем баз данных составляет ~ 400 гбайт (чуть больше 30 баз). Все запросы никто в здравом уме логировать не будет (ну вы же понимаете, что за минуту это будет ~150 тысяч строк текста) - соответственно, логируются только те запросы, которые выполняются дольше других. Есть ситуация: 8 магазинов (это ИМ на опенкарте, 4-6 млн товаров в каждом) обладают никакой посещаемостью. Мы обожглись на том, что наблюдая возросшую нагрузку на сервер БД увидели в логах именно запросы от этих магазинов: базы были вытеснены из ОЗУ и не попадали ни в дисковый кэш, ни в буферы марии. Как результат, хоть нагрузка была высокой, но именно наименее нагруженные базы отправляли запросы в логи, тогда как истинные виновники - пара магазинов с возросшей посещаемостью, в логи не попадали. Причиной оказалось то, что тогда как нагруженные висели в ОЗУ, не нагруженные нужно было каждый раз поднимать с диска, а затем они снова вытеснялись из кэшей ввиду низкой активности. Такие вот дела.

Я конечно не спец по таким большим вещам, но тут кмк вопрос в неправильной настройки логгирования. Или же настойки очереди доступа/ресурсов в базу.

Но в любом случае - эта ситуация не типична и не говорит о том, что юзер не может получить логи медленных вопрос по СВОИМ базам.

А вообще...этот случай описывает ситуацию, когда виновные оказались одни, а пострадали другие юзеры. И тут уже вина хостера, как ни крути.

SeVlad, Видимо, вы не в курсе, как работают серверы БД. Там нет приоритизации запросов, очередь - "первый вошёл - первый вышел", плюс паралельное исполнение запросов по числу ядер.

Хостер в этом случае были мы, и пользователи не пострадали, т.к. в этом случае вопрос решался наращиванием ресурсов с нашей стороны. Но дело не в этом, я привёл не зря агаву, как одного из таких вот хостеров. Такими же вещами страдали и другие не маленькие конторы, в том числе и из присутствующих на этом форуме.

Я это веду к тому, что достаточно массовый хостинг он не может предполагать индивидуального подхода, что выливается вот в такие вот проблемы. В обычном случае такие вещи должны решаться индивидуально. А у любого, сколь-нибудь серьезного хостера нагрузки будут поболее наших, и там уже вряд ли кто будет разбираться крайне детально: могут просто за количество запросов отрубить, даже если они очень лёгкие и не оказывают влияния на сервер БД. Часто имеет смысл попросить перенести на другой сервер, и проблемы снимает как рукой. Именно из-за оверселлинга конкретного сервера. Такие примеры можно ии на серче, наверное, поискать.

Именно так я и понимаю.

И ещё знаю, что как правило, у хостеорв есть лимиты на кол-во одновременных запросов и времени их исполнения. Агава тут далеко не одинока. И я не считаю это не правильно (если лимиты адекватные конечно).

SeVlad, Нет, я не говорю, что это не правильно. Лимиты есть и у нас. Просто подходы у разных контор разные. Для понимания претензий к агаве (в последствии рег.ру) - вот этот сайтик на древней джумле с посещаемостью в 1 человек в день (uk-argillit.ru) отрубался за нагрузку именно за MySQL. Размер БД - 17 (!!) мегабайт. Я не представляю, каким запросом можно превысить лимиты времени исполнения у такой маленькой базы.

Частный случай, в серьёзной конторе послали в лес. После переноса на фрихост оно заработало нормально.