>Boris A Dolgov, теперь я озадачился еще больше. И как тогда быть? Если я получаю только ~50% от заявленной в ТП мощности CPU при загрузке 100% по top'у, это никак не проверить?
Скорее всего, нет. Только купив аналогичный процессор и проведя на нем какой-нибудь бенчмарк, достаточной длительности, чтобы действие соседей адекватно размазалось по времени.
>А про hyper-thrading это правда, что 50% от заявленного в ТП получаю я? Просто у меня unixbench в описании CPU что-то про HT писал. А среди флагов /proc/cpuinfo имеется флаг ht.
Вы, видимо, перечитали хабрапомойку :)
На самом деле, одно ядро падает по производительности где-то в 1.3 раза при включении ht. Но так как ядер становится в два раза больше, суммарно получается рост, а так как в OpenVZ у VPS нет процессоров и ограничений, в итоге Вы выиграете.
Прочитайте формулировку процессорного ограничения на сайте хостера.
Если там описано что-то вроде "2 ядра по 1000 Mhz", то он заведомо Вас обманывает (возможно, даже не подозревая об этом), так как OpenVZ (да и никто другой) не может отрезать от процессора мегагерцы и прикрепить к виртуальному серверу.
Если там написано что-нибудь вроде "10% от 1 ядра XEON XXX", то она - нечеткая и к ней можно придраться. Во-первых, под ядром можно понимать физическое ядро (тогда надо либо выключать HT, либо при включенном HT выдавать в два раза больше ядер виртуальному серверу), а можно и виртуальное (тогда при HT достаточно давать одно ядро). Во-вторых, это никак не управляет кешем и самим процессором - в пике Вы всегда можете потребить хоть все 100%, но дальше пойдет разделение на порядочного и непорядочного хостера. У порядочного 10% Вам будут всегда гарантированы, а у непорядочного - нет. Способа проверить, что выделено и что гарантировано, тоже не существует из-за особенностей системы виртуализации.
Вообще, на openvz виртуализации процессор будет самым слабым местом в последнюю очередь. Лучше проверьте производительность диска и то, насколько память не свопится.
На OpenVZ нет понятия реально досупных мегагерц - так как у OpenVZ-впски нет процессора.
То, что показывает /proc/cpuinfo - просто информация, которую OpenVZ кладет в тот файл.
Ограничение процессора построено на расстановке приоритетов процессов, и единственное, о чем можно знать - что процесс из контейнера, у которого mhz показывается больше, получит "больший" приоритет. Значит, результаты тестов будут необъективны и будут зависеть от ситуации на ноде у соседей.
pupseg: технически - да, проблем нет.
но бывает - клиент дергает веб-сервер по 20 раз на дню.
попытки договорится и оптимизировать это - не помогают.
думаю над api менеджера... что бы сразу 200 доменов добавить например..
Кстати, в менеджере недавно появился параметр, не позволяющий рестартить панель чаще, чем раз в N времени.
>"Способы перехватить сисколлы в Linux" - как вариант - LD_PRELOAD, но тоже далеко не идеальное решение.
Ну, это фактически то же самое, что линковаться со своими open() и так далее. Всё равно остаётся проблема подсовывать это всем в env или патчить ld. Ну и проблема с количчетсвом логов и правами на них.
>Ранее были варианты перехвата в модулях ядра, но потом лавочку прикрыли во избежание. Проще патчить ядро, конечно же.
Действительно, sys_call_table больше не экспортируют :( Получается, остаются только совсем сумасшедшие кривости.
>Уверен. Я вам что хочу сказать - хостинг == надежность или хостинг != надежность? Ну можно научиться обрабатывать журнал ФС, там эти изменения хранятся, не в том виде, конечно, не в удобоваримом. Да, именно... Модуль - правильнее. Легче != правильнее.
Журналируемая ФС не записывает все происходящие изменения. То, что она записывает не имеет какого-то API и соглашений - всё остаётся на совести реализации. Так что перешли с ext3 на jfs или ext4 - переписываем нетривиальный модуль.
Да, похоже на микрософт - красивые картинки и много букв.
А на самом деле-то это работает? Вы запускали?
>Boris A Dolgov, теперь я озадачился еще больше. И как тогда быть? Если я получаю только ~50% от заявленной в ТП мощности CPU при загрузке 100% по top'у, это никак не проверить?
Скорее всего, нет. Только купив аналогичный процессор и проведя на нем какой-нибудь бенчмарк, достаточной длительности, чтобы действие соседей адекватно размазалось по времени.
>А про hyper-thrading это правда, что 50% от заявленного в ТП получаю я? Просто у меня unixbench в описании CPU что-то про HT писал. А среди флагов /proc/cpuinfo имеется флаг ht.
Вы, видимо, перечитали хабрапомойку :)
На самом деле, одно ядро падает по производительности где-то в 1.3 раза при включении ht. Но так как ядер становится в два раза больше, суммарно получается рост, а так как в OpenVZ у VPS нет процессоров и ограничений, в итоге Вы выиграете.
Прочитайте формулировку процессорного ограничения на сайте хостера.
Если там описано что-то вроде "2 ядра по 1000 Mhz", то он заведомо Вас обманывает (возможно, даже не подозревая об этом), так как OpenVZ (да и никто другой) не может отрезать от процессора мегагерцы и прикрепить к виртуальному серверу.
Если там написано что-нибудь вроде "10% от 1 ядра XEON XXX", то она - нечеткая и к ней можно придраться. Во-первых, под ядром можно понимать физическое ядро (тогда надо либо выключать HT, либо при включенном HT выдавать в два раза больше ядер виртуальному серверу), а можно и виртуальное (тогда при HT достаточно давать одно ядро). Во-вторых, это никак не управляет кешем и самим процессором - в пике Вы всегда можете потребить хоть все 100%, но дальше пойдет разделение на порядочного и непорядочного хостера. У порядочного 10% Вам будут всегда гарантированы, а у непорядочного - нет. Способа проверить, что выделено и что гарантировано, тоже не существует из-за особенностей системы виртуализации.
Вообще, на openvz виртуализации процессор будет самым слабым местом в последнюю очередь. Лучше проверьте производительность диска и то, насколько память не свопится.
На OpenVZ нет понятия реально досупных мегагерц - так как у OpenVZ-впски нет процессора.
То, что показывает /proc/cpuinfo - просто информация, которую OpenVZ кладет в тот файл.
Ограничение процессора построено на расстановке приоритетов процессов, и единственное, о чем можно знать - что процесс из контейнера, у которого mhz показывается больше, получит "больший" приоритет. Значит, результаты тестов будут необъективны и будут зависеть от ситуации на ноде у соседей.
Думаю, если хакер выложит эксплоит, то будет худо всем.
Если Вы о Continuous_data_protection как технологии, то патч реализует почти это.
Если о решении от r1soft - то ещё нужно смотреть, насколько оно кривое и проблемное.
технически - да, проблем нет.
но бывает - клиент дергает веб-сервер по 20 раз на дню.
попытки договорится и оптимизировать это - не помогают.
думаю над api менеджера... что бы сразу 200 доменов добавить например..
Кстати, в менеджере недавно появился параметр, не позволяющий рестартить панель чаще, чем раз в N времени.
А у них есть решение для кластера? Что оно умеет?
>"Способы перехватить сисколлы в Linux" - как вариант - LD_PRELOAD, но тоже далеко не идеальное решение.
Ну, это фактически то же самое, что линковаться со своими open() и так далее. Всё равно остаётся проблема подсовывать это всем в env или патчить ld. Ну и проблема с количчетсвом логов и правами на них.
>Ранее были варианты перехвата в модулях ядра, но потом лавочку прикрыли во избежание. Проще патчить ядро, конечно же.
Действительно, sys_call_table больше не экспортируют :( Получается, остаются только совсем сумасшедшие кривости.
>Уверен. Я вам что хочу сказать - хостинг == надежность или хостинг != надежность? Ну можно научиться обрабатывать журнал ФС, там эти изменения хранятся, не в том виде, конечно, не в удобоваримом. Да, именно... Модуль - правильнее. Легче != правильнее.
Журналируемая ФС не записывает все происходящие изменения. То, что она записывает не имеет какого-то API и соглашений - всё остаётся на совести реализации. Так что перешли с ext3 на jfs или ext4 - переписываем нетривиальный модуль.
Увы, с manager'ом ничего не получится придумать - он берет конфигурацию ввв-доменов из конфига апача.
nginx можете переделать, создав в нём один какой-нибудь левый виртхост вроде
server {
listen 80 default;
location @backend { proxy_pass http://127.0.0.1; }
location / { proxy_pass http://127.0.0.1; }
location ~ регексп_из_исп { root /var/www/symlinks/$host; error_page 404 = @backend; }
}
madoff все понял и апнул тему )))
[irony]
пишите нужно смотреть
[/irony]