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