А нехватку собственных ресурсов Вы не допускаете?
Я понимаю, что сейчас рискую этим обсуждением еще больше запутать ТС, но я объясню. (Может быть, модераторам стоит вынести это в раздел "Администрирование").
Вы только что сказали, что при загруженной хост-системе idle 0%:
Я ответил - это можно проверить, сняв все задачи в гостевой системе, так, чтобы она ничего не делала.
Если idle в этом случае будет 100%( или стремиться к нему, если хотите) значит оверсела нет.
Во-первых, тут Вы себе же противоречите.
Во-вторых, ваше уточнение в скобочках может сбить с толку и меня, и Вас, и ТС.
0% idle означает лишь одно - контейнеру не хватает процессорного времени (безотносительно причины).
И тут уже на мой взгляд, нехватает именно процессорного времени, установленного хостером.
Что я вижу:
1) ТС сидит на слабом тарифе.
2) Статистика держится стабильно с самого начала использования.
Вот если бы у ТС был большой тариф, ТС долго и счастливо использовал свой VPS, а потом - упс! куда девалось мое процессорное время? Тогда да - была бы другая картина с признаками оверселла.
К тому же, как уже сказали, usage 10-15% вполне соответствует доли 400Mhz от 2.3-2.6Ghz ксеона
Вот это как раз нормально - при изменении выделенного процессорного времени для контейнера в Xen'е usage процессов изменяется в тех же пропорциях. Если контейнеру дать 200% процессорного времени(то есть 2 процессора или 2 ядра), то cpu usage для активного процесса будет 200%.
Посмотрите первые whitelist'ы по Xen'у - разработчики в это и закладывали смысл более эффективной утилизации железа: задачи, которые не умеют работать многопоточно, получали ресурс всей многопроцессорной машины, а не только 1 процессор.
Это тоже можно проверить, взяв более старший тариф или попросить хостера временно предоставить cpu по более старшему тарифу - на Xen это можно сделать даже без рестарта контейнера для чистоты эксперимента. При остутсвии овеселла usage должен стабильно держаться уже 20-30%.
Тогда ТС-у нужно просто снять все задачи в системе и посмотреть top.
Если на разгруженной системе idle в шапке top'а будет 100%, значит прав я, если idle будет 0%, значит Вы правы.
Но почему-то мне кажется, буду прав я :)
Как я понял, ТС запостил вывод top'а, когда система была загружена установкой ISPManager.
Все ж написано - IDLE - по нулям, значит контейнер съел весь ресурс cpu, выделенный ему. Сдается мне, при оверселле был бы виден свободный idle в контейнере. Если не прав, поправьте.
По опыту общения с qemu-related виртуализациями - 100% утилизацию можно было было увидеть, только если контейнеру был бы предоставлен весь логический cpu или ядро физического cpu.
Не знаю, что такое 400Mhz в конкретной конфигурации, но это определенно не целый процессор, и если бы Вы наблюдали 100% утилизацию - вот это уже был бы серьезный повод ждать оверселл от хостера.
Вряд ли можно продавать по 256MB памяти и сразу по целому процессору без оверселлинга.
Ну, и отсутствие свопа скорой установке тоже не способствует.
Вот это уже не нормально. Похоже, ТП ответила про виртуальный хостинг, не поняв вопроса или не вникнув, о какой услуге речь.
Кому, простите, и лопата - костыль, если ее использовать, как костыль. :)
chroot - вполне адекватный себе механизм.
Для построения окружений под аккаунты есть проект http://sourceforge.net/projects/jail/
Позволяет на скорую руку собрать нужные либы для chroot'нутого аккаунта.
.
Можно трогать, почему нет.
Qmail действительно не знает, что делать, если вынести структуру директирии очереди.
Для деликатного вмешательства в очередь есть утилита http://sourceforge.net/projects/qmhandle/
Интересный угол зрения, но, мне кажется, Вы здесь путаете - по аналогии - лицензия на производство охотничьего ружья у производителя не дает лично Вам права его использовать без каких-либо разрешений. Никакого отношения лицензии и сертификаты Dr.Web к предмету обсуждения не имеют. Их лицензии касаются производства подобного программного продукта - это тесно связано с криптографией, в частности.
Мне кажется, чтобы покопаться в юзерских файлах, хостеру достаточно прописать в своих правилах - оставляю за собой право проводить аудит и вносить изменения по необходимости. И уже дело пользователя согласиться с этим, либо нет.
На большой клиентской базе наверняка, как минимум, сложно каждого держать за ручку и заставлять следить за своим кодом, процент отклика будет маленьким. Хотя, и внимание к клиентам, и беспокойство на эту тему это, безусловно, в плюс хостеру.
Если права была моя учительница французского, то правильно "We don't accept" :)
Скандалы интриги расследования. Это все есть на roem.ru и с комментариями сочувствующих.
За всей этой хроникой увлекательно наблюдать, а только много ли людей ринулось продавать свои шевроле и сузуки после новостей про банкротство GM.
amso добавил 16.04.2009 в 03:31
Cогласен. Более того, считаю, что для серьезных специалистов оказаться в хостинг компании - это что-то из категории "вляпаться".
Меняйте хостера, адекватная ТП должна сообщить хотя бы направление решения проблемы, не в смысле в каком направлении Вам идти, а указать технические нюансы и способы их решения.
Каждый хостер это собственные нюансы - от технических до организационных. В общем смысле хостеры тут непричем.
Если Вы хотите детально разобраться в причинах каких-то технических проблем, но нет своего специалиста , делайте, как делают все остальные - просто обращайтесь на тематические форумы(тот же соседний раздел Администрирование) по каждой проблеме, тамошнее сообщество гуру-энтузиастов и горе-гуру-энтузиастов Вам помогут понять суть проблемы.
