4ГБ Оо ужасть. чтобы БД в притык на свопе шевелилась. кошмар, зажем же HDD насиловать.
4диска.. сасы...
16Гиг памяти и Zfs, тем более isp на лайте напилили поддежку zfs, и будет счастье.
кэшируете, memcache + apc, на одном венике можно нормально выжать всю нагрузку что у вас.
под эти задачи даже i3 хватит с головой.
Для ТС, информация к размышлению:
http://www.rldp.ru/mysql/mysqladm/tables.htm
пункт: 7.6.10 Поддержка мультиверсионной обработки
Почитайте внимательно, если у Вас был Innodb формат, то размеры будут отличатся, ведь в innodb данные не удаляются.
Очень плохо что Вы не описали всей картины происходящего, выглядит она так:
Поступает заявка на сброс системы, её выполняют.
Поступает заявка на КВМ так как система не отвечает, КВМ предоставляют оперативно и тут оказывается что клиент не владеет навыками работы с КВМ.
Заявка передается администраторам, но ответы от клиента поступают с задержками.
Причина сбоя: kernel паник во время загрузки user space, клиент переложил отвественность на поддержку.
Действия администраторов: оперативная проверка диска на ошибки, так как даже ось не грузилась, ругаясь на проблему gpt, загрузка в single mod, проверка диска, дальше комманда return и kernel panic.
Все на попытки выяснить что будем дальше делать и как востанавливать клиент не отвечает.
Мы со своей стороны стараемся предоставить максимум поддержки и качества, но вот такие случаи к сожалению...
а нафига тогда в 43 мы выиграли войну?
А ведь предупреждали об этом, рано или поздно начнут все расплачиваться.
И что? проигнорировали, авось пронесет, пронесло.
Интересно а кто несет теперь ответственность и как будет происходить возмещение материального и морального ущерба?
