donsergios, Сначала объясните, зачем вам InnoDB на таких объемах. Да можно и не плагином, а просто превращать сайты в статику, если уж на то пошло. И у вас ОДНА ольшая база, или НЕСКОЛЬКО? Или МНОГО НЕБОЛЬШИХ?
Если там много мелких баз то, боюсь, оптимизировать там будет нечего, кроме как превращения сайтов в статику по крону, к примеру.---------- Добавлено 21.08.2019 в 15:29 ----------LEOnidUKG, Да не важно. Кто сказал, что он вообще что-то у меня купит? Я тут, как бы, хочу проблему решить, а убедив человека, что ему железо нужно потому, что нужно - это сделать себе хуже, не? Воот. Тем паче, что клиент не мой и ко мне вряд ли обратится в обозримом будущем. Но вот исходя из опыта, если бы человек мог оптимизировать - он бы это сделал.
Я вообще-то не хостер, а админ. Прочитайте мой первый пост в этой теме.
baas, В данном случае хоть заоптимизируйся. Если нужна выборка по всей базе - она надолго.---------- Добавлено 21.08.2019 в 15:13 ----------donsergios, Можете ещё mysqlcheck --all-databases --optimize прогнать. Это дефрагментирует БД и, скорее всего, ускорит работу с ними. Но до определённого момента.
Нужно уже бюджет огласить.
Нет, берите диски в RAID. Т.е. 2 HDD + 2 SSD. Оперативки по максимуму. Ну и т.п. Вам, по идее, консультация в мессенджере нужна. Создайте тему в разделе "хостинг", со ссылкой на эту, пусть хостеры предлагают и обсуждают, а там вы уже и поймете, что вам нужно.---------- Добавлено 21.08.2019 в 15:03 ----------
Что там выяснять? У него запрос по большим БД. Раз товарищ решил нарастить ресурсы - пусть наращивает. Ну вы же понимаете, что случайное чтение по 100 ГБ базе не будет быстрым по определению? А ещё пока идёт выборка по такой базе - будут тормозить и более мелкие.
Да там нужно и индексы смотреть, и вообще запросы и т.п. Но 100 Гбайт и мгновенно - как-то не вяжется. С учетом, что в InnoDB 19 гигабайт, а запрос поди читает все строки из базы - ну, чего ж там уже дёргаться то. Там надо или переделывать всё или железо менять на то, которое хоть как-то будет тащить. Если это ИМ - однозначно менять железо.
Ну и какой объем ваших БД? Естественно, что они не влезают в память и читаются с диска.
Вообще, крайне рекомендуется второй диск поставить в RAID, особенно при такой нагрузке.
В целом, можете вынести базы на SSD - проблема обращения к диску вас беспокоить перестанет.
Ну, а так - у вас там все базы большие? или много маленьких? Если много маленьких - наращивайте ресурсы. Если пара больших БД, а остальные мелкие - разбираться надо именно с ними.---------- Добавлено 21.08.2019 в 01:26 ----------P.S> ну, а вообще тест вы выполняли на линейные чтение/запись, арндомные чтение/запись у вас в пределах нормы для HDD. Даже не плохи, я бы сказал.
suffix, Генерация. PHP выполняет дополнительные действия, чтобы положить страницу на диск (кэширование выполняется средствами PHP у веб-мастеров, кэш на стороне сервера это DevOps или админ). Потом при запросе страницы нужно проверить, а кэш истёк или нет, и если он истёк (скажем, 5 минут, а посещение раз в полчаса) - удалить старые данные из кэша, сгенерировать новые, отдать клиенту и положить снова в кэш. Если таких страниц на сайте (условно) миллион - то выигрыш от такого кэша нулевой, когда кэш истекает раньше, чем будет повторно отдан. Это заставляет CMS использовать больше ОЗУ, больше делать запросов к БД, генерировать больше обращений к диску, а так же производить дополнительные действия на CPU.
Ну, это было во-первых. Во-вторых, умные ребята с Redis и прочими кэширующими системами. Чем больше кэш, тем больше занимает выборка из него, и опять же, если закэшированы десятки гигабайт данных, то вполне вероятен сценарий, когда обращение к кэшу будет происходить дольше, чем генерация страницы без кэша. Особенно файловый кэш средствами CMS.
Дальше продолжать? Если хотите - почитайте, почему кэширование средствами MySQL не эффективно, когда кэш слишком большой и предлагается использовать кэш на уровне приложения. Не надо сравнивать взрослые вещи с кэшированием в cms.
Ага. А потом этот кэш отдать. При том, что перед выдачей данных из кэша - сначала нужно валидировать кэш. В случае, если посещаются куча разных страниц, выигрыш от кэша отрицательный. И да, блин, может. Я не разбирался, по каким алгоритмам оно там работало, но отключение кэширующих плагинов снижало нагрузку на пару порядков.
Bananzz, скажем, учи матчасть. Генерация кэша сама по себе ресурсы кушает, и далеко не всегда уместна. Это не то кэширование, которое ты тут нам усиленно описываешь. И да, в вордпрессе оно реализовано, мягко говоря, плохо в очень многих случаях. Тут тебе говорят про конкретный продукт, а не про баззворды.
Судя по сообщению нихрена не знаешь и не умеешь. Там кэш файловый, если что, обычно.
А что не так? Чернушники только так и делают, они ходят с ломаных дедиков или через тор/впн.
Ну, а про битки... это удобно только в одном случае: если у вас доход в битках. В остальных случаях это как раз очень неудобно. Так что всё понятно с таким клиентом.
