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

123 4
SeVlad
На сайте с 03.11.2008
Offline
1609
#11
lonelywoolf:
LSAPI я не ставлю в шаред по той причине, что это приведёт к дополнительным телодвижениям по поддержке, к которым я не готов. Того же мнения и мои коллеги: выигрыш перед mpm-itk минимален и заметен только в хайлоаде.

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

И чем же?

lonelywoolf:
Нет, он вряд ли вам может сказать, насколько именно грузят именно _ваши_ запросы сервер БД.

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

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Связь со мной через http://wp.me/P3YHjQ-3.
lonelywoolf
На сайте с 23.12.2013
Offline
151
#12

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

Платный и бесплатный хостинг с защитой от DDoS (http://aquinas.su)
SeVlad
На сайте с 03.11.2008
Offline
1609
#13

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#14
SeVlad:
И чем же?

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

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

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

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

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

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

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

SeVlad:
Nginx без апача на шареде - это ахтунг для юзеров.

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

SeVlad
На сайте с 03.11.2008
Offline
1609
#15
lonelywoolf:
Тем, что мейнтейнить его и ставить в систему придётся самому, а в CL это сделали за меня.

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

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

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

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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#16

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

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

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

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

SeVlad
На сайте с 03.11.2008
Offline
1609
#17
lonelywoolf:
Как результат, хоть нагрузка была высокой, но именно наименее нагруженные базы отправляли запросы в логи, тогда как истинные виновники - пара магазинов с возросшей посещаемостью, в логи не попадали

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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#18

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

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

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

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

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

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

lonelywoolf
На сайте с 23.12.2013
Offline
151
#20

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

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

123 4

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий