ihor.ru: VDS с SSD от 250 р, Сервера, Хостинг в Москве. / 4

Возникла проблема, ночью задал по Москве около 10 вопросов, на каждый получил ответ в течении 10 минут. Удивило.

sidorka, Давайте ближе к делу, я ответил Вам в тикет.

Ivan Lungov, именно такой ответ я и хотел прочитать собственно - "на айпи такой-то защита не срабатывала". Понадобилось три дня и ваше вмешательство. Отправил список айпи своих серверов - надеюсь получить такой же лаконичный ответ - срабатывал антиддос или нет. Большего мне от вас не нужно.

ЗЫ. Почему ваши все время просят рут дать? Который раз уже. Пирогами торгуют что ли втихаря от начальства?

Стандартная процедура, проверить изнутри сервера все. Снаружи не всегда понятна проблема. И в 90% случаев проблема именно внутри сервера.

Не знаю у них ли это проблема или они ввели лимиты не понятно. Это случилось

внезапно прошлой недели. Переписка с тех поддержкой ничего не помогла, постоянно твердили перейти на ssd. Что типа hdd слаб, типа что она была всегда таким. У меня 1 один сайт большой на друпале на которым в день около 30-40 просмотров, который постоянно пишет в базу всякие мелочи. Потому что он настроен так что лежит все в ОЗУ, всякие кэши и сессии в мэмкэше, сам код в opcache тоже в памяти.

млин, какой-то update полей в mysql записывал на диск около секунды.

скорость:

Мне хватило бы этих 15.4 MB/s но проблема в том что iotop (и ещё смотрел atop -Dd) показал

скорость 0 MB/s несколько секунд а потом бах больше 200MB/s а потом опять меньше 100кб/с

а этот dd не показывает нулевые моменты, он берет средную.

У меня сайт начал открываться по 10 сек. ужас ужас ужас. slow_query log

показывал что update запросы проходили очень медленно.

top показывал:

47.1 wa - это ужас

я отрубил все сайты думал может на сайт какие то движение пошли.

вроде бы исчезло все крутяк.

но запросs update mysql на тестовом базе и на тестовой таблицы пустой таблицы

выполнялся то 500ms то больше секунду.

Это было ужас 2 дня лежал сайт пока разбирались, сайт с одного на другой сервер переносили

ничего не помогало, пока не перешел ssd.

Вот ssd что показывает:

wa не поднимается выше 2%

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

Не хочу сказать что они плохие они молодцы, отвечают каждый 10-15 минут. За это спасибо!

Особенно Атджанов. Так он единственный который заметил вроде бы проблему, и они сейчас в данный момент разбираются. Вроде бы)

А другой твердил постоянно что типа из за hdd. Hdd сам по себя медленный. Ну это же смешно))

Мне переплачивать лишных сто рублей не хочется, мне и hdd хватало. Так как у меня реально не большой iops

Вот такие вот пироги)

PS. кстати заказал сделать образ моего диска, у них 2 утра до 4 чтобы могли отключать сервер и сделать мне нормальный образ, что вы думаете просыпаюсь от звонка клиента что типа с 6 утра уже не доступен сайт. Я залезаю в биллинг там сообщение, что они не успели снять образ, образ снять только на 1/3.)) А время уже 9 утра)))

в i/o то кто "уходит"?

mysql видимо, а конкретнее innodb сбрасывает каждую транзакцию на диск

Можно переключить innodb_flush_log_at_trx_commit в 2 (так данные будут в кеш ОС попадать и раз в пару сек на диск сбрасываться)

Более подробнее можно погуглить и решить как будет лучше

Это не решение проблемы, я эти вещи знаю. Но это не выход.

У меня же кроме mysql есть и другие операции с диском.

Например, хотел обновить какой-то пакет, запустил apt-get upgrade и он обновляет пакет пол часа это нормально что-ли? А перезагрузка сервера, которая проходило максимум минуту, вдруг перезагружается где-то за полчаса это тоже?

С соседями по хосту просто не повезло

Если запись на диск идет постоянно или даже чтение с диска, то для HDD это убийственно. Учитывайте то, что на сервере еще соседи. Средненький HDD имеет ограничений в 100 IOPS, учитывая то, что на сервере скорее всего не менее 10 соседей, то на каждого клиента приходится 10 iops. Если по простому, то операции с дисков свыше 10 (если строго считать) за единицу времени будут вставать в очередь и ждать завершения. Здесь варианта два - либо внутри контейнера проблема, либо на ноде, где лежит Ваш виртуальный сервер.

Проверяется легко - отключаете все процессы (mysql, httpd, nginx и прочие, которые взаимодействуют в диском), по сути, у Вас должен остаться минимальный набор процессов необходимый для работы операционный системы. Включаете top - если значения wa или st высоки, значит проблема на ноде. Также можно посмотреть load average. Но это всё верно будет только тогда, когда Вы на 100% уверены, что у Вас ничего не взаимодействует с диском на сервере и не грузит процессор.

Если первый тест выдал близкие к нулю значения wa и st, значит проблема внутри vds или Вам действительно просто не хватает ресурсов hdd. На ssd конечно же всё будет летать, там запаса iops хватит на всех клиентов с лихвой.

Евгений Русаченко, от такой команды там вовсе ничего поднимается и не может. На HDD в том же числе. wa должен оставаться равным 0.

Или вы о другой команде?