Как мартышка, не читая?
Логи посмотреть. И на "чистом" и на "грязном" nginx - это всегда работает.
Вы пропустили самый существенный пункт:
- необходим человек, который бы сформулировал вменяемое техническое задание
Как вам правильно заметили, настроить "чтобы все в один миг" - далеко не всегда возможно в принципе. Мало-ли какой замороченный движок вы используете, мало-ли какие у вас могут быть требования к возможности кеширования контента.
Во-вторых, зачем вам ISP ради двух-то сайтов? :)
Компетентный человек прежде всего не будет убеждать вас в чем-либо за такую смешную сумму. На пообедать не хватит :)
Подумайте об этом.
Поверьте, это всем тут уже очевидно:
Дорогая, бездумная погремушка.
Сходить к гадалке.
Купить себе еще мак, сто маков. Они зацветут и тырнет в доме магиццки появится.
Описание "проблемы", скажем так, весьма туманное. Но если так уверены, что дело не в сайте - смените хостера. На хорошем хостинге клиенты изолированы друг от друга.
Можно, не вопрос. Если бюджет окажется не смешной, если скрипты собственного сайта проверите, если после настройки сервер будут сопровождать.
Про то что дело в swap вы подметили верно, а вот конкретный предложенный вами механизм - неверен. Дело не в "большой нагрузке".
А почему сразу не какой-нить Potato? В нем еще и версия ядра 2.2.x. Ведь насоветуете некрофилии - а кому-то потом идиотский ТЗ от ТС расхлебывать.
Если памяти > 4Gb, то да.
Выбор дистрибутива - выбор вашего администратора. Хотите проблем - делайте выбор за него.
У вас же был нормальный диск. Судя по первым примерам логов и вывод /proc/mdstat - ошибки сыпались с того диска, на который шел ребилд (тогда это был sda). Если ну уж очень хочется бекап сделать - ну и выньте сбойный диск из райд, затем *запишите* на него бекап (ошибок чтения не будет - сектора уйдут в ремап или "починятся"). Дальше - вынимайте сбойный диск и замените его новым.
Видимо бравые хлопцы запустили вам ребилд со сбойным диском в качестве основного, оттуда и ошибки чтения.
Все можно, но не вам, извините. Учиться треба, а вы пока умения делать сие не показали. Но если ну очень интересно: http://smartmontools.sourceforge.net/badblockhowto.html
Вообще, чего вы хотите от местных админов? Набираться "мудрости" и давать потом ЦУ сотрудникам ДЦ, которые выполняют ваши задачи? От таких советов вам в итоге будет только хуже - хорошо, когда вы выполняете работу самостоятельно либо не мешаетесь под ногами у тех, кто все делает.
То, что стоит других читать, чтобы не повторять советы в десятый раз.
И читать научиться сперва.
Что-то до 2.6.19 ядра было (хз когда этот патч включили в CentOS). Может rsync, вместо recovery, но точно не check.
Нормальные диски. Последняя строчка - говорит в пользу плохого кабеля.
Ох, телепаты...
Есть "вероятность", а есть 100% уверенность, что это просто разные модели дисков, которые отображают SMART-данные по-разному. Вот то что кажет один из них - вас и напугало с непривычки.
"Эта ошибка" непосредственно ни о чем не говорит. Причины могут быть разные.
Сервер доступен по SSH, просто с консоли? Если да - смотрите логи.
