- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
LSAPI я не ставлю в шаред по той причине, что это приведёт к дополнительным телодвижениям по поддержке, к которым я не готов. Того же мнения и мои коллеги: выигрыш перед mpm-itk минимален и заметен только в хайлоаде.
Неужели LSAPI затратнее в поддержке чем другие модули?
И чем же?
Нет, он вряд ли вам может сказать, насколько именно грузят именно _ваши_ запросы сервер БД.
Чёй-то? В проблемных запросах не видно название базы?
Наверное, придётся пояснить, почему FPM не всегда быстрее prefork/itk. Дело в том, что в случае FPM запускается враппер и держит на готове запущенные копии интерпретатора PHP. То же самое, в общем, делает и Prefork/itk с той лишь разницей, что оно запущено уже непосредственно в процессах апача в виде модуля. Nginx быстрее апача только в некоторых сценариях и опять же, в хайлоаде это нужно обычно (всё же апач универсальнее). Когда ресурсов хватает - разница на глаз незаметна.
lonelywoolf, да в легенды "Nginx быстрее апача" я не верю :). Я прекрасно понимаю что всё зависит от конкретных условий и использования. И ещё прекрасно понимаю, что Nginx без апача на шареде - это ахтунг для юзеров.
Но это никак не отвечает на мои вопросы.
И чем же?
Тем, что мейнтейнить его и ставить в систему придётся самому, а в CL это сделали за меня. Но я жадный и не хочу платить за CL (тем более, что у меня свой взгляд на вещи). Соответственно, это уже менее стандартная конфигурация.
Чёй-то? В проблемных запросах не видно название базы?
Ну вот давайте смоделируем.
Есть какой-то сайт, он дергает базу постоянно, и от этого она много думает. Но сами по себе запросы выполняются быстро, вызывая только нагрузку на CPU. Когда таких запросов много (возможности CPU исчерпываются) - сервер БД начинает их выполнять медленнее все. И те, которые были бы при нормальных условиях выполнены быстро, при нагрузке начинают валитсья в лог медленных запросов, даже если они не виноваты в этой нагрузке.
Рассмотрим другой пример. Какой-то пользователь постоянно получает из БД данные, и эти данные кэшируются в кэше MySQL (хотя при большом трафике кэш обычно выключают, но не всегда). В результате повышения нагрузки на сервер БД админ лезет смотреть лог медленных запросов и туда попадают не те, которые создают нагрузку, а те, которые просто время от времени выполняются и вымываются из кэша.
Можно придумать много таких сценариев, где не шибко компетентные хостеры садятся в лужу именно на подобных ошибках. Т.е. я веду к тому, что если запрос выполняется медленно - не значит, что виноват именно этот запрос (в условиях, когда сервер БД нагружен большим количеством пользователей на базах с разной частотой использования и разной структурой). Поэтому часто предпочитают ограничивать именно частоту и длительность запросов вместо того, чтобы разбираться. Агава, например, этим грешит.
---------- Добавлено 20.07.2019 в 01:04 ----------
Nginx без апача на шареде - это ахтунг для юзеров.
Я даже больше скажу: иногда Nginx даже вреден. Его обычно используют, чтобы сэкономить память на отдаче статики: ему не нужно в каждом процессе держать интерпретатор PHP со всеми его модулями, поэтому апач занимается обработкой PHP и не грузит на отдачу каждой картинки всё своё барахло, только когда оно нужно. Но ещё Nginx может испортить картину, отдав картинку напрямую, даже если в .htaccess выставить Deny (от так бывает в некоторых конфигурациях).
Тем, что мейнтейнить его и ставить в систему придётся самому, а в CL это сделали за меня.
Хм.. Ну другие-то модули php и апача для др ОС всё равно надо ставить.
И это же разовая операция.
Или я что-то не понимаю?
Ну вот давайте смоделируем.
Ну смоделировали.. В запросах (в логах точнее) есть и база и время выполнения и др данные.
В чем же проблема опознать виновника?
SeVlad, Ну почему же. Что-то делает за нас ISPSystem, а что-то делают сборщики дистрибутива ОС. И уж RedHat (на котором базируется CentOS) как правило, ребятки поумнее большинства среднестатистических админов и вряд ли накосячат там, где накосячит по ошибке/неопытности/невнимательности обычный среднестатистический админ. Я вот, к примеру, хоть и считаю себя серьёзным специалистом, но звёзд с неба не хватаю и явно могу ошибиться с бОльшей вероятностью при сборке этого софта. Или могу не учесть какие-то мелкие нюансы, которые могут проявиться при очередном обновлении софта.
Ну то есть, сделать то можно, но при отсутствии явных преимуществ нет желания плодить лишнюю точку отказа.
Ну смоделировали.. В запросах (в логах точнее) есть и база и время выполнения и др данные.
В чем же проблема опознать виновника?
Хорошо. У нас сервер БД выполняет 20-50к запросов в секунду (!). Объем баз данных составляет ~ 400 гбайт (чуть больше 30 баз). Все запросы никто в здравом уме логировать не будет (ну вы же понимаете, что за минуту это будет ~150 тысяч строк текста) - соответственно, логируются только те запросы, которые выполняются дольше других. Есть ситуация: 8 магазинов (это ИМ на опенкарте, 4-6 млн товаров в каждом) обладают никакой посещаемостью. Мы обожглись на том, что наблюдая возросшую нагрузку на сервер БД увидели в логах именно запросы от этих магазинов: базы были вытеснены из ОЗУ и не попадали ни в дисковый кэш, ни в буферы марии. Как результат, хоть нагрузка была высокой, но именно наименее нагруженные базы отправляли запросы в логи, тогда как истинные виновники - пара магазинов с возросшей посещаемостью, в логи не попадали. Причиной оказалось то, что тогда как нагруженные висели в ОЗУ, не нагруженные нужно было каждый раз поднимать с диска, а затем они снова вытеснялись из кэшей ввиду низкой активности. Такие вот дела.
Как результат, хоть нагрузка была высокой, но именно наименее нагруженные базы отправляли запросы в логи, тогда как истинные виновники - пара магазинов с возросшей посещаемостью, в логи не попадали
Я конечно не спец по таким большим вещам, но тут кмк вопрос в неправильной настройки логгирования. Или же настойки очереди доступа/ресурсов в базу.
Но в любом случае - эта ситуация не типична и не говорит о том, что юзер не может получить логи медленных вопрос по СВОИМ базам.
А вообще...этот случай описывает ситуацию, когда виновные оказались одни, а пострадали другие юзеры. И тут уже вина хостера, как ни крути.
SeVlad, Видимо, вы не в курсе, как работают серверы БД. Там нет приоритизации запросов, очередь - "первый вошёл - первый вышел", плюс паралельное исполнение запросов по числу ядер.
Хостер в этом случае были мы, и пользователи не пострадали, т.к. в этом случае вопрос решался наращиванием ресурсов с нашей стороны. Но дело не в этом, я привёл не зря агаву, как одного из таких вот хостеров. Такими же вещами страдали и другие не маленькие конторы, в том числе и из присутствующих на этом форуме.
Я это веду к тому, что достаточно массовый хостинг он не может предполагать индивидуального подхода, что выливается вот в такие вот проблемы. В обычном случае такие вещи должны решаться индивидуально. А у любого, сколь-нибудь серьезного хостера нагрузки будут поболее наших, и там уже вряд ли кто будет разбираться крайне детально: могут просто за количество запросов отрубить, даже если они очень лёгкие и не оказывают влияния на сервер БД. Часто имеет смысл попросить перенести на другой сервер, и проблемы снимает как рукой. Именно из-за оверселлинга конкретного сервера. Такие примеры можно ии на серче, наверное, поискать.
Видимо, вы не в курсе, как работают серверы БД. Там нет приоритизации запросов, очередь - "первый вошёл - первый вышел", плюс паралельное исполнение запросов по числу ядер.
Именно так я и понимаю.
И ещё знаю, что как правило, у хостеорв есть лимиты на кол-во одновременных запросов и времени их исполнения. Агава тут далеко не одинока. И я не считаю это не правильно (если лимиты адекватные конечно).
SeVlad, Нет, я не говорю, что это не правильно. Лимиты есть и у нас. Просто подходы у разных контор разные. Для понимания претензий к агаве (в последствии рег.ру) - вот этот сайтик на древней джумле с посещаемостью в 1 человек в день (uk-argillit.ru) отрубался за нагрузку именно за MySQL. Размер БД - 17 (!!) мегабайт. Я не представляю, каким запросом можно превысить лимиты времени исполнения у такой маленькой базы.
Частный случай, в серьёзной конторе послали в лес. После переноса на фрихост оно заработало нормально.