так, а что мешает делать бэкап самим, хотябы дамп базы скидывать можно хоть каждый день на тот же @gmail.com :)
лучше постарались бы сделать так, чтобы это не повторилось:
1) поставьте на комп антивирус нормальный (рекомендую KIS)
2) проверьте все на вирусы, выкачайте сайт к себе на комп и проверьте все, возможно где-то в папках лежит шел-скрипт
3) смените ФТП пароли, а также пароли на почтовый ящик и на сам хостинг-аккаунт
4) обновляйте движок чаще
а если есть дедик в hetzner'е, то зачем тебе ВПСка? :)
еще можно попробовать складывать сессии PHP в хранилище eAccelerator'а :)
также в настройках SMF выбрать агрессивное кеширование (уровень повыше поставить) eAccelerator/memcached, а также почаще в админке проводить "удалить незначительные логи" + "оптимизировать таблицы" :)
ну у них и процессор десктопный, так что наличие десктопных дисков в принципе не удивительно, да и это не столь важно, главное, чтобы соотношение цена\качество удовлетворяло :)
хороший процессор, такой средне-бюджетный вариант, правда он не серверный, но это не главное, главное - как его загрузили вычислениями :)
до определенного момента дает, а потом как не крути, больше уже не выжать
кстати можно попробовать еще включить в nginx'е кеширование на такие локейшны как:
/index.php?action=profile
т.е. на все участки форума, которые не критичны к частым обновлениям
ну если диски хорошие, серверные, а не бюджетные SATAшные, то в принципе они проработают отлично 2-3 года без проблем хоть в постоянно 100% нагруженном состоянии (конечно бывают исключения, но обычно браковки вылетают в течении первого месяца) :)
тогда будет конкретная деградация производительности, т.е. 20 сек. рендеринг странички - это будет еще оптимальным показателем...
а вот хостеру поставить отдельный сервер (с отдельным гигабитным шнурком до рабочей ноды) с SSD дисками под MySQL было бы очень кстати + выдавать на каждую ВПСку например по 5-20 баз в зависимости от тарифного плана, тогда бы и XEN'ки клиентов бегали бы шустрее и клиентам приятно и хостеру не так уж и расходно :)
или хотябы экономичный вариант - на ноду влепить отдельный шустрый диск(и) и сделать одну XENку чисто под БД, оптимизировать все хорошо чисто под БД)
просто когда БД клиентские лежат в одном дисковом пространстве (пусть даже RAID-10/50), то при активном свопинге время позиционирования по диску (для БД как раз очень важно) возрастает до очень больших значений и деградирует всю производительность ноды, клиент конечно может там у себя крутить key_buffer, sort_buffer_size/read_buffer_size/read_rnd_buffer_size, но это все не поможет при активных insert'ах, так как в любом случае нужно производить запись на диск, да и query-кеш тут уже мало чем поможет :)
PS: можно попробовать часть таблиц перекинуть в MEMORY хранилище, это значительно разгрузит систему, только надо понимать, что содержимое MEMORY таблиц стирается при банальной перезагрузке (хотя в SMF полно хлама - те же логи-модерации и т.п., которых не жалко потерять), также советую выключить диск-хранилище в eAccelerator'е, так как он порождает серьезную фрагментацию диска (как бы мне тут не доказывали то, что в линухе фрагментации нет), также можно создать блочные (файловые) устройства, и разделить в них БД, /var/log + /tmp, - это снизит фрагментацию и в теории повысит быстродействие :)
ну вот как может быть производительность, если идет множественная рандомная выборка (типичный свопинг)? - время доступа ухудшается при этом до безобразия, и скорость работы с БД падает...
вот если как-нить сконфигурировать так, чтобы юзеру предоставлялось под БД доп. дисковое пространство (в виде еще одного устройства) на 15к RPM дисках (или SSD) дисках - вот тогда решение было бы хорошее...
ну это не катит для масс-ВПС-хостинга, а для VIP хостинга лучше уж OpenVZ - и гибче и как-то более адекватнее в плане отказоустойчивости, и вообще те же 8 дисков можно в RAID-50 (при наличии хорошего контроллера разумеется) и реализовать уж тогда лучше через VMWare или Hyper-V :)
ну если эти не помогли, значит причина реально в хостере
ну у хостера видимо дисковая система тормозит, все же хотят денежкофф, вот и сэкономили... XEN еще такая штука, парочка свопящихся ВПСок и деградация производительности всей ноды обеспечена :)
и как это решит проблему с диском?
линейная скорость чтения\записи дискового массива (например RAID-10 из 4-х дисков 1Тб) будет порядка 250Мб\сек, а рандомное чтение будет еле дотягивать 10Мб\сек, в результате при массивном свопинге скорость просядет так, что там как раз выше этих 10Мб не будет подниматься :)
то ли дело SSD диски, там что линейная, что рандомная - практически нет разницы, так как позиционирование практически мгновенно происходит - но редкие хостеры предоставляют VPS'ки на SSD'шниках :)
вот, все реально, более того - востребовано, например дорвейщиками и любителями SAPE :D
поставил бы rus-to-lat плагин и не мучался бы с битыми ссылками :)
я сравнивал производительность платформы, что она из себя представляет это вторично...
во многих случаях сверх бюджетные дедики в бюджетных ДЦ - это по сути дела те же тауэр-декстопы, так что разница между "неттопами" и такими дедиками идет явно в пользу "неттопов"...
сравнивать десктопы и серверные платформы разумеется бесполезно, это разные вещи :)
кстати в декстопно-домашнем сегменте уже давно HP присмотрелась к Атому, вот пример:
http://hard.compulenta.ru/423340/
а еще интереснее вот это:
http://www.xard.ru/post/14810/
т.е. можно ожидать в скором времени и нормальных законченных решений в 2U конструкции с кучей серверов (некий такой Blade-micro :) )
причем реализовать для них единый KVM, один общий SAN массив на все серверы горазда проще и дешевле, чем это реализовывать отдельными решениями в стандартной стойке
по сути дела можно получить мощный кластер размером в 2U, по производительности превышающий целую стойку "средних" по мощности\цене серверов :)
