Teppa, значит не надо брать выделенный сервер и использовать его на 20-30%
Перейдут на VPS, займутся оптимизацией.
Shi3A, как наивно полагать что цены в РФ останутся на таком же уровне.
MNERU, так они явно такими ценами говорят "платите за лицензии каждый месяц" ;)
ISPmanager 4 - dead, относительно скоро уйдет из продажи. Для тех у кого в биллинге есть v4 - какое-то время еще будет возможен заказ.
По ONBOOT="yes" - конечно же.
VE_STOP_MODE=suspend в глобальном конфиге /etc/vz/vz.conf
Не ловил такое. Если снова поймаете - пожалуйста, отправьте репорт в багзилу.
Скорее всего из-за этого https://bugzilla.openvz.org/show_bug.cgi?id=2969
Проблему с сокетами после ансуспенда - пофиксили.
От изменения ядра - не зависит.
Есть. VE_STOP_MODE=suspend
Так трассировку сделайте в обе стороны.
WapGraf, я же сразу написал - что нет ничего плохого в CPU*1.5 + дополнительный лимит по CPUUNITS.
Для клиента это обычно - бесполезная информация. Если сайты на VPS работают быстро и стабильно - никто даже не задумывается о количестве соседей на ноде.
Если начинаются проблемы - нужно общаться с тех поддержкой хостинга. Если вопрос не удается решить или узнать в чем конкретно проблема - хостингов много, можно выбрать другой.
Хотя конечно огромные цифры по CPU/ RAM/ HDD + очень дешевая цена = повод задуматься.
RAM/ IOPS/ HDD - это крит параметры для ноды.
Если mysql выделил себе N RAM - то назад он их не вернет.
С CPU - наоборот, возможен как рост нагрузки, так и падение. Например с 21.00 до 23.00 - пик. А в 03.00 до 05.00 - нагрузка на ноде будет минимальна.
Если нагрузка на диск в норме (IOPS), а CPU load 60~70%, то скорость будет высокая.
В тоже время если CPU в простое, а нагрузка по IOPS высокая, то в целом заметно снизится скорость работы ноды .
Добавляя дополнительный лимит по CPUUNITS - мы можем гарантировано выделить количество CPU на контейнер.
Процессор 8 потоков -> по "3400Mhz" и 6 контейнеров.
Вариант 1: можно разделить CPU -> 8*3400/6 = 4533Mhz => то есть от 2 потоков по 2x2266Mhz
Вариант 2: можно разделить так -> 8*3400*1.5/6 = 6800 Mhz => 2x3400Mhz
Плюс добавить равный вес по CPUUNITS и при 100% нагрузке всех контейнеров по CPU -> каждый контейнер получит 2x2266Mhz.
Второй вариант лучше - потому что утилизация CPU на ноде не 100%. И выгоднее - чтобы контнейнер быстрее обработал запрос, чем упирался в лимит.
Быстрее обработал - быстрее освободил CPU.
Аналогично и с каналом, если трафик позволяет - лучше дать немного шире канал, чем урезать его.
Так же за счет этого - клиент получит больше за меньшие деньги. При нормальной работе ноды - лучше более высокая утилизация ресурсов - чем простой.
