Судя по вашему vmstat в момент, когда вы его снимали все было нормально. Дисковая активность небольшая, процессор большую часть времени бездействует, ожидание данных в разумных пределах.
Если трудности сохраняются - обращайтесь в асю.
еще, кажется в виртуозе работает команда
vmstat 2
дайте сюда вывод строк 10-20
XEN тоже можно оверселлить. По диску без вопросов. Просто порочную практику оверселла ввели виртуозовцы. При этом есть серьезные провайдеры с жесткой системой качества, которые предоставляют нормальные услуги на основе даже виртуозы. Тут прикол в том, что виртуоза система, удобная для менеджеров, а с тормозами на сервере разбираются не они. А когда попаришься с кучей машин виртуальных, на которых оверселл по диску или памяти (что приводит к свапу) на основе виртуозы - начинаешь ее сторониться. XEN сейчас по стоимости приблизился к виртуозе, возможностей и предсказуемости для технаря гораздо больше. С панельками пока только не такой широкий выбор.
Есть скриптик iotop, можно его поставить и попробовать помониторить.
Но если это Vituozzo VPS, то проще оттуда свалить. Виртуозу очень любят менеджеры - очень просто устроить оверселл (нажал кнопку - VPS создался). И если нет жесткой системы качества - дальше сами поймете. Объяснять им, что оверселл - это не хорошо, когда они и сами это понимают, значит сталкиваться с лицемерием. Проще тупо свалить. Делов часа на два после заказа нового VPS (лучше на XEN), при наличии nginx достаточно просто будет настроить проксирование на новый IP (пока будет обновляться DNS).
Нужна помощь - обращайтесь в асю или жаббер.
Если глобально, я бы ушел с Virtuozzo на XEN http://www.truevds.ru/price либо http://openhosting.ru/. Правда первые вообще без панели управления и ее нужно ставить отдельно, а вторые предлагают только DirectAdmin.
Если нужна помощь, чтобы разобраться, почему не хватает ресурсов на текущей площадке - обращайтесь в асю.
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $newwidth, $newheight, $width, $height);
Это жрет ресурсы процессора в юзерспейсе (это где 45%). sys (55%) - это отжирание процессора в ядре. Причем не ожидание ввода-вывода, т.к. FreeBSD такие ожидания показывает в idle (Linux в wait). Судя по выводу top проц жрут MySQL и Apache. Для MySQL цифра точная 11% (он не форкается, плодит и убивает потоки, но процесс один), для апача, который форкается и киляется цифры в top неточные.
55% процессора в ядре - это форки-киляния процессов апача в пределах Min/MaxSpareServer, возможно своп одних процессов апаче, пока работают другие.
дай вывод
строк 10-20, тогда станет более понятно.
сборка драйвера с сайта реалтека, скорее всего, достаточно простая процедура. И провести ее можно и без KVM (если уж его нет). Просто перед каждой операцией, в результате которой есть риск остаться без сети нужно ставить машину на ребут минут через 5. Снос и полная переустановка - это крайняя мера.
Так что если есть доступ к машине по сети (хоть какой-то), то я бы переставил драйвер. Прикол в том, что об этом очень подробно нужно будет знать постоянному админу, т.к. при любом обновлении ядра нужно будет заново настраивать сетевой драйвер.
Погуглил по
NETDEV WATCHDOG: eth0: transmit timed out
r8169: eth0: link up
Похоже на косяк драйвера сетевушки. Выходов вижу два. Поставить драйвер из исходников с сайта реалтека, как рекомендуют. Либо попросить провайдера воткнуть в машину другую сетевуху (другого производителя). Машина наверняка арендованая, не колокейшин, поэтому уболтать провайдера вполне реально (вы же при выборе провадера учитывали простоту общения с ним? :-) ). Если, конечно, в машине остались свободные слоты. В обоих случаях нужен будет IP-KVM и лучше, чтобы эту операцию производил постоянных администратор, т.к. нужно будет в деталях знать, что проделали.
В случае установки новой сетевухи - перенастроить сеть можно разрешить и провайдеру (думаю это реально, покрайней мере, когда у меня был колокейшин я на такое убалтывал саппорт среди ночи, дело было в россии). Саппорт, обычно, не любит, когда их назойливо просят сделать какую-нибудь ерунду. В реальной трудности, помогают (если конечно, клиент не сам себе трудности создает). И это как раз случай, когда требуется их помощь.
тогда проще его залить из консоли, зайдя по ssh, либо графическим клиентом, который умеет делать ssh туннели, типа SQL Ёга.
Я так понимаю, там через phpMyAdmin пытаются дамп передать, а на UPLOAD лимит установлен.
Загружать нужно через что-то другое...
В асю стукни или в жаббер.
