ru_openvz

UPD.: Хм — только что случайно нашёл как минимум один ответ вида «не очень».

День добрый.

Существуют какие-либо рекомендации по подбору
oomguarpages.barrier, vmguarpages.barrier, privvmpages.barrier, privvmpages.limit? Точнее как оптимальнее подобрать разницу между ними:
i = vmguarpages.barrier - oomguarpages.barrier
j = privvmpages.barrier - vmguarpages.barrier
k = privvmpages.limit - privvmpages.barrier

Если я хочу выделить VPS, скажем 256Mb? Это значение я присваиваю privvmpages.barrier, а сколько оптимальнее давать остальным? http://wiki.openvz.org/UBC_systemwide_configuration - читал, но в общем там рекомендации по "системе в общем", т.е для всех VPS...

На что еще я не обратил внимание? Какие параметры учитывать? Что еще почитать?

Оригинал и перевод.

Есть в ядрах (openvz) 2.6.18? Как вообще с поддержкой данного расширения в openvz? Какие подводные камни могут вылезти?

Я тут разразился программным постом на тему $SUBJECT. К сожалению, на английском, но там вроде не язык Шекспира, должно быть всё понятно.

• в openvz: On vSwap and 042stab04x kernel improvements
• в Google+ OpenVZ page: On vSwap and recent 042stab04x kernel improvements

Краткое содержание:

1. vSwap: зачем он нужен (потому что UBC черезчур сложны) и почему он чудесен (потому что понятен и прост)
2. внутренности vSwap: какая память считается и почему
3. улучшения в 042stab04x ядрах (дальше, выше, быстрее!)

PS а ещё в последнем ядре удвоен ответ на главный вопрос жизни, вселенной и всего такого!

Тут один человек написал пост про OpenVZ. Вроде бы надо пройти мимо и не тратить время, но меня зацепило, поэтому далее подробный разбор.

Если подумать, можно обнаружить, что довольно много софта, который мы используем, не является стабильным, не смотря на название конкретных версий.

Например, openvz.

Прочитав это, я обеспокоился. Подумал, у человека какой-то серьёзный баг, он полгода тщетно пишет нам в багзиллу, а мы игнорируем и не чиним. Так ведь бывает иногда -- то времени нет, то баг не воспроизводится, то у нас и у пользователя разные представления о его (бага) критичности.

Читаю дальше.

Я уже неоднократно писал про полное отсутствие суппорта со стороны что разработчиков, что комьюнити,

Хмм. Не баг. Сокрушается отсутствием саппорт со стороны разработчиков и комьюнити. Причём тут стабильность вообще? Какая-то внезапная подмена зелёного на квадратное произошла.

Про разработчиков могу сказать, что у нас примерно 10 кернель дивелоперов плюс я. Если мы начнём посвящать своё рабочее время саппорту пользователей, OpenVZ очень быстро загнётся. Как говорил проф. Ф.Ф. Преображенский, "если я, вместо того, чтобы оперировать, каждый вечер начну у себя в квартире петь хором, у меня настанет разруха".

Про комьюнити -- по сути, автор поста сам себя критикует, он и есть часть комьюнити.

и вот ещё один пример - я несколько дней написал вопрос на форуме - vzmigrate without ssh or any encryption. 1160 просмотров темы и ни одного ответа за 5 дней. Что я могу сказать, всем на это просто положить.

Я посмотрел, у него 78 сообщений на forum.openvz.org, и это топики, начатые им, с его вопросами. Я не просмотрел все 78 постов, конечно, но я не смог найти ни одного, где бы он сам помогал другому пользователю. Зато увидел какое-то количество ответов наших дивелоперов -- и теперь мне жалко их времени, оно явно могло быть потрачено с бОльшим толком.

Опенсорс -- это симбиоз разработчиков и сообщества, где все друг другу помогают. А это -- паразит, нахлебник. Это и по его высказыванию видно, и по виду активности в форуме.

Что делать, в принципе ясно. Перестать всё это использовать.

Вот тут я полностью согласен и горячо подддерживаю! Я не вижу смысла в таком вот пользователе, который использует продукт, ничего не давая взамен. Но, с другой стороны, и плохого в таком пользователе ничего нет. Но он пошёл дальше -- он не желает читать документацию, думать, смотреть в шелл-скрипты и учиться. Вместо этого отнимает время у разработчиков, а потом критикует как их, так и сам продукт.

К счастью, не всё комьюнити состоит из таких неприятных людей, что доказывают хотя бы комменты coolcold к тому посту.

vzctl stop VEID --fast не отрабатывает:
Stopping container ...
Unable to stop container: operation timed out
войти в контейнер невозможно, процессы с материнского сервера убить kill -9 не удается.
Смотрим процессы:

ps auxwww| awk '{print($2)}'| xargs vzpid| grep VEID

kill -9 PID -- и ничего, они остаются висеть:

ps auxwww| grep 837896
33 837896 0.1 0.0 320484 20952 ? D Oct13 1:52 /usr/sbin/apache2 -k start

Что делать? Рестартовать хост не получится, там много других виртуалок. Ядро 2.6.18-238.5.1.el5.028stab085.3

На виртуалке в одной папке скопилось ОЧЕНЬ много файлов (2М7). Количество файлов довольно точно совпадало с выводом

vzlist -a -o veid,diskinodes -s diskinodes

после файлы удалили, а значение в выводе практически не изменилось. Что где не так? Ядро 2.6.18-238.12.1.el5.028stab091.1