Очень субъективный взгляд на хостинг 1gb.ru

sap, 13-го мая 2009 года в 18:55

Обращаю ваше внимание на то, что эта запись является архивной. Ей уже больше 3 лет. Это означает, во-первых, то, что мое мнение по поднятым в ней вопросам могло измениться (хотя, конечно, не обязательно), а во-вторых, то, что я не испытываю никакого желания эти вопросы обсуждать, и поэтому комментарии и оценки я отключил.

Я не претендую на объективность. Цель этой записи — высказать своё максимально беспристрастное мнение о хостинге 1gb.ru. У меня с ними вышла некрасивая ситуация, которую я хочу описать, и сделать из нее субъективные выводы.

Итак, у нас есть проект «Великие слова». С самого начала (а именно, с февраля), мы хостились у товарищей 1gb — так сложилось, что ранние проекты хостились у них, ну и решили новый проект разместить там же. Еще до того, как мы запустили проект, меня начал настораживать тот факт, что ночью сайт стабильно лежит по несколько минут, иногда и несколько десятков минут. Было мнение, что это связано с тем, что ночью бэкапятся сайты. Да, весьма достойный повод класть сайты. Ну да ладно.

Когда мы запустили проект, на нас обрушился «хабраэффект». Хостеры не преминули отреагировать — сайт был закрыт. Пришлось спешно менять тариф на другой, с достаточным лимитом CPU. Аж 10%, если память меня не подводит. Насколько я знаю, 1gb — один из вымирающих мастодонтов, у которых до сих пор в ходу такие лимиты. Ну да ладно.

Кстати, за 3 месяца, проведенных у этого хостера, у них 3 раза проводился «ремонт оборудования в дата-центре». Это, конечно, очень мило, что хостер заботится о своем оборудовании, но, опять же, сайты лежали по несколько часов, и компенсировать время простоя никто и не подумал. Ну да ладно.

Итак, проект работает, растет, и вроде бы все хорошо. Учитывая специфику навигации и загрузки страниц (абсолютно все страницы у нас загружаются с помощью технологии Ajax), я решил написать внутреннюю систему статистики. И написал. Но с тогдашними 5000 хитов в сутки, она было довольно тяжелой с точки зрения быстродействия. И в один прекрасный день было получено сообщение:

В вашем аккаунте зафиксировано превышение квоты на загрузку сервера баз данных.
База данных, превышающая квоту: gb_greatwords

(смотреть сообщение полностью)

В вашем аккаунте зафиксировано превышение квоты на загрузку сервера баз данных.
База данных, превышающая квоту: gb_greatwords

Параметры запроса, вызывающего проблему:
(приводятся параметры одного из запросов)

Время исполнения, секунд - 11
Кол-во просмотренных строк - 799637
Запрос:
-------
use gb_greatwords;
SELECT count(*) FROM `ii_visits_statistic` WHERE `time`<"1239998400";
-------

ВАЖНО: ключевой параметр - количество просмотренных строк, а не время исполнения запроса (время роли не играет).

Загрузка сервера баз данных, вызываемая вашим сайтом, превышает нормы, допустимые для виртуального хостинга. Работа базы данных в этом режиме нарушает предсказуемость работы сервера, мешает другим пользователям сервера.

Вам необходимо модифицировать скрипты, отказаться от выполнения запросов, аналогичных предыдущему, либо оптимизировать структуру таблиц или запрос.

Если вы хотите продолжать пользоваться нашими услугами, вам необходимо в короткий срок решить проблему. Ваш аккаунт или БД может быть заблокированы, так как подобная нагрузка может вызывать перегрузку сервера баз данных и отказ в обслуживании для других клиентов.

(скрыть)

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

Новая статистика нормально себе работает, потребляет гораздо меньше места в БД и подавляющее большинство запросов я переписал и оптимизировал. Все нормально, и проблем вроде нет. Но 1gb считает иначе, и в еще один прекрасный день мы получаем сообщение:

База gb_greatwords остановлена.

(смотреть сообщение полностью)

База gb_greatwords остановлена.

Запросы вида: SELECT T.`quote_id`, T.`content`, T.`author`, T.`source`, T.`year_or_age`,
TA.`name` AS `author_name`, TAR.`name` AS `second_author_name`,
TK.`word_id`, TK.`keyword`, TF.`user_id` AS `favorite` FROM `ii_quotes_approved` AS T
JOIN `ii_authors` AS TA ON T.`author` = TA.`id`
LEFT JOIN `ii_authors` AS TAR ON TA.`related` != 0 AND TA.`related` = TAR.`id`
LEFT JOIN `ii_keywords_to_quotes` AS TT ON T.`quote_id` = TT.`quote_id`
LEFT JOIN `ii_keywords` AS TK ON TT.`word_id` = TK.`word_id`
LEFT JOIN `ii_favorites` AS TF ON T.`quote_id` = TF.`quote_id`
WHERE T.`quote_id`="74" OR T.`quote_id`="155" OR T.`quote_id`="157" OR T.`quote_id`="187" OR T.`quote_id`="279" OR T.`quote_id`="327" OR T.`quote_id`="334" OR T.`quote_id`="361" OR T.`quote_id`="405" OR T.`quote_id`="413" OR T.`quote_id`="458" OR T.`quote_id`="624" OR T.`quote_id`="625" OR
...

SELECT count(*) FROM `ii_visits_statistic` WHERE `time`<"1241467200";

не используют индексы и вызывают 100% загрузку процессора.

(скрыть)

Сайт, естественно, лежит — он не может работать с отключенной БД. По милости 1gb мы пропускаем 600 уникальных посетителей, или 10+ тысяч хитов в сутки. Мы падаем в рейтинге поисковых систем, потому что наблюдать сообщение «Ошибка при работе с базой данных» поисковым роботам не нравится. В общем, что рассказывать о последствиях длительного лежания сайта?

Забегая вперед, скажу, что больше всего меня во всей этой истории поражает свинское поведение 1gb, а именно отключение базы без каких-либо предупреждений. Предыдущее сообщение относилось абсолютно к другому скрипту и абсолютно другому запросу. Я не считаю подобную практику приличествующей серьезной хостинг-компании, не говоря уже о том, что это просто по-человечески нехорошо.

Разумеется, я начинаю переписываться с саппортом, пытаясь решить проблему. Попутно мы принимаем решение взять себе выделенный сервер. Вообще-то, мы уже подумывали над этим, и первым кандидатом на приобретение VDS был как раз 1gb. Нужно ли говорить, что теперь мы их услугами не воспользуемся? Останаливаемся на хостинг-провайдере «ColoCall», и, хотя пока преждевременно говорить о качестве услуг, но за прошедшее время всё на высоком уровне.

Впрочем, о переписке с саппортом. Приводить ее полностью не буду, так как очень много текста. Расскажу вкратце: я отключаю систему статистики (из нее второй запрос в сообщении), и отписываю об этом саппорту. В ответ молчание. Несмотря на то, что договор с новым хостером уже подписан, нужно подождать несколько дней, пока наш сервер запустят в работу, и не хочется, чтобы сайт все это время лежал, потому я забиваю на статистику и следующим письмом предлагаю саппорту удалить таблицу `ii_visits_statistic`, которая и используется в «проблемном» запросе (не могу не признать, что индексы в нем действительно не используюся) — благо, свежий бэкап базы на руках. Что же касается первого запроса — то я, не обращая внимания на наглое вранье саппорта, что, дескать, запрос не использует индексы, отвечаю, что на все поля, по которым осуществялется JOIN, ORDER BY, GROUP BY индексы стоят. Кроме того, подобные запросы используются постоянно (напоминаю, 10+ тысяч хитов в день) и как-то странно, что вдруг этот запрос взял и вызвал дикую, бешеную нагрузку.

В ответ получаю следующее:

Таблицу ii_visits_statistic удалили, но без решения проблемы по первому запросу включить БД не можем. Аргументы вида "сколько лет всей деревней гайки отвинчиваем и хранил господь" (А. П. Чехов, "Злоумышленник" - http://www.ostrovok.de/old/classics/chekhov/story031.htm) мы принять не можем.

Молодцы, хорошо пошутили. Только сайт как лежал, так и лежит. То, что индексы используются, с первого раза не дошло. Чтобы дошло со второго, привожу список самих индексов, показываю, как они используются, и прилагаю скрин выполнения «проблемного» запроса с EXPLAIN, на котором хорошо видно, что индексы используются. В ответ мне молчание аж до следующего дня.

Так как 1gb, несмотря на явную свою неправоту, БД включать не собираются, мы временно заливаем базу на другой хостинг и подключаем ее с помощью удаленного доступа. После двух дней дауна сайт наконец-то возобновляет работу.

Только на следующий день мне приходит ответ, в котором говориться, что EXPLAIN в качестве аргумента саппорт принять не может, и соображения по поводу того, что MySQL плохо обрабатывает запросы со множеством джойнов. А то я не знал. Конечно, медленно, но, мне показалось, или сначала они что-то говорили по поводу того, что якобы не используются индексы? По просьбе читателей 1gb, привожу текст этого письма.

Есть несколько соображений:

1. EXPLAIN не показывает фактическое положение дел, это только предположение о том, что будет происходить. Не всегда верное.
2. mySQL крайне плохо обрабатывает JOIN по множеству таблиц с дополнительными параметрами, в большинстве случает строится просто временная таблица с перемноженными таблицами участвующими в запросе.

смотреть письмо полностью

Есть несколько соображений:

1. EXPLAIN не показывает фактическое положение дел, это только предположение о том, что будет происходить. Не всегда верное.
2. mySQL крайне плохо обрабатывает JOIN по множеству таблиц с дополнительными параметрами, в большинстве случает строится просто временная таблица с перемноженными таблицами участвующими в запросе.
3. У вас практически нет составных индексов, при этом используется (в идеале) только какой-то один индекс, другие игнорируются и для исполнения запроса не используются.
4. Большое количество параметров перечисленных через OR или в IN (...) просто множат запрос. Если у вас запрос SELECT fignya FROM tblErunda WHERE id=5 потребляет на исполнение запроса 100 условных ресурсов, то SELECT fignya FROM tblErunda WHERE id=5 OR id=7 будет потреблять уже 200
5. Выдержка из лога медленных запросов на примере одного запроса. Сам запрос (полностью) ниже. Таблицы участвующие в запросе: ii_quotes_approved - 2 353 записи, ii_authors - 763, ii_keywords_to_quotes - 6 991, ii_keywords - 1 735, ii_favorites - 5 621. В сумме 17463 записей, 845 килобайт данных. И так, запрос по логу медленных запросов mySQL при исполнении во временных таблицах обработал 637 207 строки. То есть, он перебрал ВСЕ строки из указанных таблиц (о каких индексах вообще в этом случае идёт речь?) минимум 36 раз, для этого он прошелся по объёму данных в 30 мегабайт.

Нужно поправить. EXPLAIN тоже принять не можем.

use gb_greatwords;

SELECT T.`quote_id`, T.`content`, T.`author`, T.`source`, T.`year_or_age`,
TA.`name` AS `author_name`,
TAR.`name` AS `second_author_name`,
TK.`word_id`, TK.`keyword`,
TF.`user_id` AS `favorite`
FROM `ii_quotes_approved` AS T
JOIN `ii_authors` AS TA
ON T.`author` = TA.`id`
LEFT JOIN `ii_authors` AS TAR
ON TA.`related` != 0 AND TA.`related` = TAR.`id`
LEFT JOIN `ii_keywords_to_quotes` AS TT
ON T.`quote_id` = TT.`quote_id`
LEFT JOIN `ii_keywords` AS TK
ON TT.`word_id` = TK.`word_id`
LEFT JOIN `ii_favorites` AS TF
ON T.`quote_id` = TF.`quote_id`
WHERE T.`quote_id`="6" OR T.`quote_id`="8" OR T.`quote_id`="25" OR T.`quote_id`="88" OR T.`quote_id`="98" OR T.`quote_id`="101" OR T.`quote_id`="124" OR T.`quote_id`="169" OR T.`quote_id`="203" OR T.`quote_id`="205" OR T.`quote_id`="207" OR T.`quote_id`="208" OR T.`quote_id`="225" OR T.`quote_id`="331" OR T.`quote_id`="333" OR T.`quote_id`="334" OR T.`quote_id`="337" OR T.`quote_id`="355" OR T.`quote_id`="356" OR T.`quote_id`="398" OR T.`quote_id`="550" OR T.`quote_id`="569" OR T.`quote_id`="586" OR T.`quote_id`="592" OR T.`quote_id`="592" OR T.`quote_id`="619" OR T.`quote_id`="692" OR T.`quote_id`="692" OR T.`quote_id`="740" OR T.`quote_id`="843" OR T.`quote_id`="845" OR T.`quote_id`="981" OR T.`quote_id`="991" OR T.`quote_id`="1007" OR T.`quote_id`="1011" OR T.`quote_id`="1013" OR T.`quote_id`="1027" OR T.`quote_id`="1134" OR T.`quote_id`="1176" OR T.`quote_id`="1256" OR T.`quote_id`="1266" OR T.`quote_id`="1354" OR T.`quote_id`="1640" OR T.`quote_id`="1659" OR T.`quote_id`="1675" OR T.`quote_id`="1679" OR T.`quote_id`="1741" OR T.`quote_id`="1779" OR T.`quote_id`="1817" OR T.`quote_id`="1823" OR T.`quote_id`="1837" OR T.`quote_id`="1845" OR T.`quote_id`="1895" OR T.`quote_id`="1952" OR T.`quote_id`="2130" OR T.`quote_id`="2272" OR T.`quote_id`="2451" OR T.`quote_id`="2458" OR T.`quote_id`="2471" OR T.`quote_id`="2482" OR T.`quote_id`="2508" OR T.`quote_id`="2532" OR T.`quote_id`="2569" OR T.`quote_id`="2594" OR T.`quote_id`="155" OR T.`quote_id`="204" OR T.`quote_id`="206" OR T.`quote_id`="318" OR T.`quote_id`="332" OR T.`quote_id`="346" OR T.`quote_id`="383" OR T.`quote_id`="393" OR T.`quote_id`="402" OR T.`quote_id`="481" OR T.`quote_id`="521" OR T.`quote_id`="608" OR T.`quote_id`="618" OR T.`quote_id`="792" OR T.`quote_id`="792" OR T.`quote_id`="880" OR T.`quote_id`="1203" OR T.`quote_id`="1209" OR T.`quote_id`="1247" OR T.`quote_id`="1251" OR T.`quote_id`="1257" OR T.`quote_id`="1676" OR T.`quote_id`="1682" OR T.`quote_id`="1819" OR T.`quote_id`="1820" OR T.`quote_id`="1829" OR T.`quote_id`="1851" OR T.`quote_id`="1854" OR T.`quote_id`="1856" OR T.`quote_id`="2307" OR T.`quote_id`="2459" OR T.`quote_id`="2461" OR T.`quote_id`="2504"
ORDER BY T.`approved_date` DESC;

(скрыть)

И раз уж я его привел, пройдусь по нему подробнее. Во-первых, если не верить EXPLAIN, то я уже не знаю чему верить. Наверно, исключительно саппорту? По второму пункту согласен, но это я и раньше знал. По третьему и четвертому тоже согласен. По пятому, у меня доступа к логами нет, так что ничего сказать не могу, но похоже на правду. То есть, в этом письме саппорт практически прав. Но мне это уже не важно. Между прочим, несмотря на новый хостинг, который легко держит сайт, я решил все же немного переписать движок, а именно, избавиться от подобных запросов. Но это тоже не важно. Важно то, что 1gb не дали мне возможности переписать движок; 1gb не предложили мне перейти на VDS; 1gb молча, без предупреждений отрубили базу — то есть положили нам сайт, лечили меня отговорками, что нет индексов, и только через 2 дня удосужились нормально описать проблему, а сайт все это время лежал.

В итоге сайт и база переносится на новый хостинг, где ужасная проблемная статистика отрабатывает за пару секунд (на 1gb она отрабатывала минимум 10 секунд), а цитаты в плейлисте меняются с такой скоростью, что кажется, как будто они не подгружаются, а уже загружены. Ну конечно, VDS же. Так вот, еще раз по поводу свинского поведения: ну что стоило 1gb не рубить нам базу без предупреждений, а предложить перейти на VDS в течении нескольких дней, а?

Итак, субъективные выводы:

• Саппорт 1gb всегда прав.
• Если саппорт 1gb не прав, он без предупреждений отключает тебе базу.
• С 1gb лучше не иметь дела.
• Я думаю, хостинг для сайтов, а не сайты для хостинга. 1gb думает иначе.
• Для более-менее серьезных проектов нужен минимум VDS.