OpenVZ Forum


Home » International » Russian » openvz kernel. vs grsec.
Re: openvz kernel. vs grsec. [message #9233 is a reply to message #9222] Fri, 22 December 2006 13:16 Go to previous messageGo to previous message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

Quote:


А что касается критики. Ну тут, насколько я понял, проблемы ориентации. Ваш продукт ориентирован на массовое предоставление root-shell, хостинга и т.п - отсюда и унифицированные имена VS, функционально упрощенная дефолтная сеть и видимость процессов/сокетов на HN.
А мне просто надоело плодить железо в серверной, а потом заниматься его апгрейдом. Где-то год назад я занялся сравнением всяких виртуальных систем - от ХЕN, до uml, но выбрал vserver, уже правда не помню почему его а не VZ Smile


упрощенная сеть? Smile обижаете! %)))) у нас как раз наоборот цель была усложнить %)) и сделать сеть максимально похожей на обычный хост.

Quote:


А про критику... А почему так много ручечек на предмет памяти?
Не проще ли просто "Максимальная память, которую может использовать этот VS"?


все очень просто, хотя на самом деле все очень сложно... :/
дело в том, что нет такого понятия как максимальная память, которую использует VS. Все люди имеют ввиду лишь память процессов. Но есть огромное количество других ресурсов, например page tables, vma и др. которые нужно считать, а иначе пользователь сможет потреблять сколько угодно памяти, не напрямую, а через ядро. Вот, например, dcachesize. Если его не ограничивать, то любой пользователь (даже на обычном Linux) сможет заставить ядро съесть *всю* память. Самый натуральный DoS, причем найти виновного будет не просто.

Quote:


Ну в крайнем случае физическая и виртуальная раздельно. Ну с памятью, тут /proc/user_beancounters помогают, чуть ли не по крону пришлось запускать проверку где чего не хватает и добавлять. А вот, к примеру, как узнать, что VSу не хватает процессора? Что пришла пока покрутить --cpuunits?
Или это я man не дочитал?


1. виртуальную память ограничивать понятно как, т.к. процессы зовут системные вызовы (типа mmap) и те могут вернуть им ошибку. это UBC::privvmpage параметр.
2. физическую память - не понятно как. В Linux нет механизма сообщить приложению о нехватке физической памяти когда происходит page fault и выделяется реальная страница памяти. Единственный способ SIGSEGV/SIGKILL. Понятно, что приложения завершают свою работу в этом случае как правило не корректно.
Это кстати, то как делают другие проекты.
Мы хотим тогда уж сделать ближе к реальной системе: physpages лимит ограничивает сколько физической памяти используется VE, все остальное вытесняется в swap как на обычной машине. На свап будет отдельное ограничение. Ну а если уж вылезли за пределы и того и другого, то OOM killer.
Не смотря на то, что этот способ ближе многим пользователям по смыслу и пониманию, есть один простой недостаток - расходуется disk bandwidth из-за таких VE превышающих physpages. А это достаточно дорогой ресурс. Иными словами, система с правильно настроенными privvmpages будет довать большую суммарную производительность, чем вот такая, "похожая" на обычные VM.

Quote:


И еще. затеялся я сделать super-mini template - ну максимум мегов на 5. C busybox-ом. Так не пошло. У вас всюду в src/vzctl
явно указано
argv[] = { "-bash"... };

exec ("/bin/bash", argv...);
exec ("/bin/sh", argv ...);

А бизибокс такого имени не знает Smile Он по имени ориетируется кем ему быть. Ну это так, мелочи...


ммм, да, есть такое... можете забить баг? в принципе, мы будем даже рады патчам %)))


http://static.openvz.org/userbars/openvz-developer.png
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Возможна ли интеграция с кластером?
Next Topic: *SOLVED* iptable in VPS
Goto Forum:
  


Current Time: Sun Aug 03 04:31:16 GMT 2025

Total time taken to generate the page: 0.91491 seconds