Mysql грузит диск

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

---------- Добавлено 21.08.2019 в 15:13 ----------

donsergios, Можете ещё mysqlcheck --all-databases --optimize прогнать. Это дефрагментирует БД и, скорее всего, ускорит работу с ними. Но до определённого момента.

Типичные слова хостера :D

Касса за углом.

Только там InnoDB, а это операция делает пересоздание таблицы. А это на 19 ГБ будет ОЙ как долго с дикой нагрузкой на диск, поэтому лучше её делать ночью и когда не делаются бэкпы. И всё же не всё сразу, а по очереди.

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

Сайты обновляются редко, я их кэширую плагином от wordpress (сброс кэша вручную, очень редко). Получается это не сильно разгружает базу?

В смысле я вообще готов кешировать сайты целиком, отдавая всё из кэша. Читал про nginx кеширование, может с ним стоит разобраться?

Или диск при этом всё равно будет нагружен, и нужно отдельно выносить базу при таких объемах?

Я вообще-то не хостер, а админ. Прочитайте мой первый пост в этой теме.

Админ хостинга, который в подписи :)

donsergios, Сначала объясните, зачем вам InnoDB на таких объемах. Да можно и не плагином, а просто превращать сайты в статику, если уж на то пошло. И у вас ОДНА ольшая база, или НЕСКОЛЬКО? Или МНОГО НЕБОЛЬШИХ?

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

---------- Добавлено 21.08.2019 в 15:29 ----------

LEOnidUKG, Да не важно. Кто сказал, что он вообще что-то у меня купит? Я тут, как бы, хочу проблему решить, а убедив человека, что ему железо нужно потому, что нужно - это сделать себе хуже, не? Воот. Тем паче, что клиент не мой и ко мне вряд ли обратится в обозримом будущем. Но вот исходя из опыта, если бы человек мог оптимизировать - он бы это сделал.

Одна самая большая на 14гб, остальные 20 сайтов по 500 мб в среднем.

InnoDB таблицы по умолчанию создаёт Wordpress, плюс начитался о преимуществах innoDB. Про большие объемы только сейчас задумался, а что с ним не так, какая альтернатива? Myisam как раз не хвалилят, что там плохо кэширование организовано как я понял.

Превращать сайт в статику - интересный вариант, сейчас гуглю как из Вордпресс это можно сделать.

Только если писали и эксплуатируют дебилы.

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

БД она для того и нужна в общем-то. Других целей её использования нету...

Но если "всё как обычно", в половине мест индексов нету, либо запросы такие что для них нету и происходит скан всей базы.

То... либо всё-таки исправить, либо попытаться запихнуть все в память.

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

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

Об однозначном преимуществе InnoDB обычно говорят те, кто в теме не разбирается и этих преимуществ не использует. Есть смысл попробовать MyISam. Но не торопитесь с этим, изначальные грабли в чем-то другом и надо решать их.

Что касается самих запросов - у Вас в слоу-квери-лог большинство запросов связанных с подсчетом количества.

Самый легкий вариант - возможно у Вас слетели индексы с таблиц, иногда бывает, тогда выборки идут без индексов и ясен пень тормозят. Сверьте базу с эталонной вордпрессной на предмет индексов. Это редкая причина, но она случается! Под "слетели" мы имеем ввиду их полное текущее отсутствие, а не какую-то "неправильную работу".

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

В любом случае запихнуть всё в память переехав на сервер не особо поможет, т.к. таким методом можно сбить 10 секунд на 1, может быть 20 на 1, но никак не 100 на 0.5 - к чему Вам надо стремиться в самом первом приближенном варианте.

---------- Добавлено 21.08.2019 в 15:00 ----------

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

Другой вопрос что проблему ТС это не решит, т.к. ВСЕ медленные запросы по 100 с лишним секунд при переезде в память никак в 200 раз быстрее не станут. Всё равно рано или поздно будет вылезать тэйблскан и грабли. Надо сначала в текущем варианте научиться из 10 секунд не выходить хотя бы.