Вполне возможно - дело именно в swap (хотя там еще несколько вариантов работы было, что приводят к аналогичному росту mismatch_cnt).
Но у меня после repair и check - все сбрасывается в ~0 (а при периодических проверках mismatch_cnt доходит до 100-200).
Чтобы успокоиться - разберитесь со smart дисков. Может там есть реальный повод волноваться. Если сервер арендуете - попросите заменить наиболее подозрительный диск и посмотрите что будет.
Можно написать им, что Вы закроете исходящие соединения, необходимые ботнету файерволом, и дальше исправите ситуацию. После такого заявления - должны открыть доступ.
Либо действительно - просите данные и переносите все на другой VPS/дедик.
Постучитесь в ЛС/почту - постараюсь помочь в любом варианте.
1) что на md2? какие файловые системы, своп есть?
2) "не равным 0" - значит равным чему??? Согласитесь, если 1 или 10 - это одно. Если 1000 - уже другое.
Короче, из вашего описания не факт - что есть реальная проблема. В нормальной ситуации такое также возможно, см.:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405919
man rsync
Но лучше доверить человеку знающему ;) Тем более, если критично избежать заметного даунтайма сайтов.
Как вариант - делаете на дедике VPS хостинг и просто тупо копируете файлы с вашего vps, а затем меняете в образе IP.
Головной мозг использовать настоятельно рекоммендуется.
С какого перепоя они не совпадут? Копируется все. Естественно, если речь идет о виртуализации virtuozzo/openvz - не нужно копировать "содержимое" dummy пакетов, которые обеспечивают на vps зависимости от функциональности, предоставляемой пакетами с ядром ОС и т.п. Эти пакеты нужно заменить реальными (установить заново), вот и все.
Реально.
Копируем, "меняем айпшники в конфигах", меняем настройки dns (делегируем на новые ns, перенаправляем записи для доменов и т.п.)
Детали (процесс по шагам, как минимизировать простой сайтов и т.п.) - Вам вряд-ли кто распишет подробно, т.к. все это достаточно индивидуально.
И будет показывать. Покуда Вы или Ваши программисты не научатся писать запросы правильно.
Он ругается на наличие большого числа временных таблиц. Не всегда можно это исправить просто крутя настройки буферов. Если используются TEXT/BLOB столбцы во временных таблицах - все равно они не будут создаваться в памяти. Либо править код - либо не считать это проблемой.
Почему? Это не статический бинарник? Дак подсуньте 32-битные библиотеки - в чем проблема? В дебиане это пакеты lib32* всякие.
А зачем Вам вообще SAS райд? Если т.з. вообще было вначале про SATA? Вы уверены, что Вам будет не хватать диска сразу, если будете использовать просто обычный райд-контроллер и софтовый рейд средствами системы? ИМХО, по описанию задачи - это далеко не очевидно.
Не, хорошо конечно, если в бюджете есть на это заначка - но может потратить на процессор/память/etc?
вот это реально дельный совет, даж не ожидал ;) для самосбора само оно.
Я не сумел телепатически выяснить, что содержится в какой-то рекламе, что Вы прочитали. Или даже технологию виртуализации, на которой работает Ваш VPS (хотя почти наверняка могу угадать).
Может "что-то типа" и сказали. Но буквально это либо чушь - либо процетировано неверно.
Вот здесь - чуть подробнее и правильнее. В частности, невооруженным глазом заметны отличия в интерпретации "проблемных" значений LA для однопроцессорных и многопроцессорных/ядерных систем...
С чего вы взяли, что "процессы стали ставиться в очередь"? По предоставленной информации нельзя судить.
"почему средняя загрузка стала XXX" - разные тому могут быть причины. От "соседей" на других VPS до какого-нибудь рутинного роста объема обрабатываемых данных. Может у вас статистика какая-то на сайтах в базы собирается. Для кучи CMS есть такие модули.
