LINUX.ORG.RU

Тесты производительности Linux и FreeBSD


0

0

Журнал Byte (http://www.byte.com) провел тесты производительности Linux и FreeBSD на типичных (по мнению byte) серверных задачах. Результаты тестов не показали существенных различий производительности, но продемонстрировали небольшое превосходство подсистемы виртуальной памяти Linux над FreeBSD.

>>> Подробности

★★★★★

Проверено:
Ответ на: комментарий от anonymous

> То есть сейчас ты мне рассказал, что виртуальному root-у ничего не
> стоит сделать свой EUID совпадающим с UID sendmail и послать последнему сигнал

Ход мысли неверный... Ну, не переживай. Еще ни один бсдун не осилил это место в мане с первой попытки ;)
Читай еще, еще, и еще... до полного, так сказать, концептуального понимания ;)

anonymous
()

Повторяю, тебя просили рассказать, _как_ ты собираешься применить
CAP_KILL для создания jail-like VM, всё без малейшего результата.
Соответственно, если мои попытки угадать, что у тебя на уме, не
удались, тады звиняй, я не телепат.

Без этого позволь считать свои слова пустой брехнёй.

anonymous
()
Ответ на: комментарий от anonymous

> О, к этому придраться невозможно. Сказано не в бровь, а в глаз.
Это на меня твои ответы на прямые вопросы так подспудно 
подействовали. А кстати, где они? 

Ладно, напишу ещё раз и без опечаток:

Пока ты не соизволишь предъявить способ, как по твоему можно 
root'a, имеющего право убить произвольный процесс в своей VM,
в том числе и процесс, который cделал setuid(x), где x != 0,
и у которого, таким образом, real uid != 0 и effective uid != 0,
лишить возможности послать сигнал произвольному процессу на машине
вообще, и при чём здесь CAP_KILL, а лучше, ткнёшь пальцем в 
соответствующий код в ядре Linux, придётся таки согласиться с 
изначальным диагнозом обострённого осеннего гона, постепенно
переходящего в не менее острую форму гона зимнего.

Заодно таки расскажи, какая capability тебе поможет ограничить
IP address binding? Cколько раз надо задать вопрос, чтобы ты его не
проигнорировал? Цепляться к опечаткам оно, конечно, солиднее.

Предъявишь (чем чёрт не шутит?) - согласен принести свои искренние извинения.

А пока - 

anonymous
()
Ответ на: комментарий от anonymous

> Пока ты не соизволишь предъявить способ, как по твоему можно
> root'a, имеющего право убить произвольный процесс в своей VM,

Твоя беда как и у предыдущего "оппонента" в том, что в голове твоей каша.
Подумай, если мы говорим о реализации bsd jail средствами linux capabilities,
то о каком таком root'e или uid==0 ты речь ведешь? Называется встретились
глухой с немым и начали беседу о том, о сем ;) Грубо говоря, твои тезисы сводятся
к тому, что если у ракеты нет крыльев, значит она не умеет летать. Глупо и неоригинально...

anonymous
()
Ответ на: комментарий от anonymous

Чудно, чудно. _Не_ root, но с правом cоздавать своих юзеров,
биндиться только к определенному IP, убивать процессы, принадлежащие
другим пользователям _только из своего окружения_, с невозможностью
нанести вред пользователям ему не принадлежащим. Это и есть аналог
jail cредствами linux capabilities. Простого описания, как ты этого 
собираешься проделать без специальной поддержки со стороны ядра
от тебя здесь и добиваются, ты же вертишься как уж на сковородке.
Можешь привести общее описание своих действий для создания такой
VM - милости просим к дальнейшей дискусии. Если нет, то твоя фраза о
том, что jail делается простой userspace утилиткой, действительности
не соответствует. Каша? Нет уж, позволь, только в твоей голове.

Вызвался делать именно jail - будь добр соблюсти условия.
Какие-то из заявленных требований действитедьно можно удовлетворить
правильной раздачей capabilities, однако ты не разродился описанием
решения как минимум двух проблем - IP и защиты от несанкционированных 
сигналов. И не разродишься, поскольку кода для их решения просто
нет в Linux ядре. 

anonymous
()
Ответ на: комментарий от anonymous

> _Не_ root, но с правом cоздавать своих юзеров,

Слава те, наконец-то понял. А если понял, что чего еще непонятно?
Существует юзер - не рут, но c полными правами рута... Отбираем у него CAP_KILL...
Как думаешь, кого он сейчас может убить? Chroot'им его, отбираем CAP_NET_BIND_SERVICE
и все, что ему не нужно. Еще почитай, что такое inheritable, permitted и
effective capability процесса, тогда не будешь задавать глупые вопросы.

anonymous
()
Ответ на: комментарий от anonymous

Это ты эту глупость предлагал мне "концептуально" постичь? Ну спасибо, утешил.

> Отбираем у него CAP_KILL... и он не может больше убивать процессы своих же пользователей. Пролетает первое условие. Он ведь процессы запускать и убивать не только под своим UID должен. Причём убрать CAP_KILL только из effective множества сараbilities ты права не имеешь, потому как первое, что проделает теоретический shellcode в случае переполнения буффера - это вернёт себе эту привилегию и см Fig. 1 :)

> Отбираем CAP_NET_BIND_SERVICE B он теряет возможность биндиться к портам < 1024, IP адрес всё-же может выбрать по вкусу из числа доступных. Пролетает условие второе.

> тогда не будешь задавать глупые вопросы. После стольких ответов концентрированной глупости, уж и не знаю. Пожалуй, таки прочти draft спецификацию Posix 1003.1e от начала до конца сам и попытайся понять наконец, что capabilities могут, а что не могу делать, и что от тебя здесь хотят добиться.

Мимо по обоим пунктам.

anonymous
()
Ответ на: комментарий от anonymous

Это ты эту глупость предлагал мне "концептуально" постичь? Ну
спасибо, утешил.

> Отбираем у него CAP_KILL...
и он не может больше убивать процессы своих же пользователей. Пролетает
первое условие. Он ведь процессы запускать и убивать не только под своим UID должен. Причём убрать CAP_KILL только из effective множества
сараbilities ты права не имеешь, потому как первое, что проделает
теоретический shellcode в случае переполнения буффера - это вернёт 
себе эту привилегию и см Fig. 1 :)

> Отбираем CAP_NET_BIND_SERVICE
B он теряет возможность биндиться к портам < 1024, IP адрес всё-же
может выбрать по вкусу из числа доступных. Пролетает условие второе.

> тогда не будешь задавать глупые вопросы. 
После стольких ответов концентрированной глупости, уж и не знаю.
Пожалуй, таки прочти draft спецификацию Posix 1003.1e от начала 
до конца сам и попытайся понять наконец, что capabilities могут,
а что не могу делать, и что от тебя здесь хотят добиться.

Мимо по обоим пунктам.

anonymous
()
Ответ на: комментарий от anonymous

> процессы запускать и убивать не только под своим UID должен

seteuid всем дочерним.

> IP адрес всё-же может выбрать по вкусу из числа доступных.
Плевать. Сервисы, типа www/ftp/smtp/pop можно пускать и супервизировать
от настоящего рута под нужным юзером. Псевдорут виртуального сервера будет иметь полный доступ
к настройкам и возможность килять сервис. Супервизирующий процесс от настоящего рута быдет поднимать их.

> Пролетает условие второе. А кто тебе сказал, что такими средствами можно на 100%
повторить bsd jail? Виртуальные сервера- это отдельная стихия. И кстати bsd jail
далеко не самый оптимальный способ их организации. Я сказал, что для многих случаев применения
bsd jail его вполне можно заменить гораздо более удобными user-space утилитами в линуксе.

По-поводу _полных_ и гораздо более приспособленных для виртуальных серверов
аналогов bsd jail я тоже писал. Есть vserver, freevsd. Ну а против таких решений как
http://www.sw.com.sg/en/hspcomplete/ bsd jail выглядит и вовсе детской игрушкой.
Полный контроль над VM и CPU в рамках виртуального сервера, управление трафиком и т.д.


anonymous
()
Ответ на: комментарий от anonymous

> seteuid всем дочерним. 
Последствия такого смелого поступка сам осознаешь, или тебе 
объяснить? Говоря товоими же словами, одолеть man page тебе не 
судьба?

> А кто тебе сказал, что такими средствами можно на 100%
> повторить bsd jail? 
Ты и сказал. Память подводит? Услужливая она у тебя. Напомню -
ты обещал сделать jail и _больше_.

> Есть vserver, freevsd.
freeVSD - это _не_ решение, а насмешка. Про vserver - согласен,
штучка один в один содранная с jail совсем плохой быть не может.
Однако тебе уже указывали, что это скорее поддерживает мои 
утвержения.
У меня проблема только с твоим бредом про userland утилитку и всё
это время я провёл пытаясь убедить некоторых знатоков в том, что 
userland-ом для создания полной VM не отделаешься. Вижу, ты этот
простой факт таки осознал.

> http://www.sw.com.sg/en/hspcomplete/
The software is currently available on Linux 2.4 kernel and will 
soon be available on Solaris8 and FreeBSD. More information is 
available at www.sw-soft.com
Вот спасибо, и впрямь интересное решение. Шансов на то, что я его
когда-нибудь применю именно на Linux, принимая во внимание наличие
более надёжной альтернативы, сам понимаешь, никакой. Настораживает 
только отсутствие исходников или каких-либо действительно подробных
технических деталей реализации. Ну не знаю я, как они там 
виртуализацию делают. Вот на мои вопросы ответят - разберёмся.
Если правильно - тогда честь им и хвала, если очередной бред a-la
freeVSD - никому они нужны не будут.



anonymous
()
Ответ на: комментарий от anonymous

> если очередной бред a-la freeVSD - никому они нужны не будут.

Не спеши радоваться. Во скажи, есть у тебя, например, два витуальных сервера.
Ты можешь дать первому серверу 60сек cpu, а второму 3600? Или первому 128 mb виртуальной
памяти, а второму - 256? Ты можешь гарантировать первому 10мбит на интерфейсе в обе
стороны, а второму ограничить входяший трафик до 500K? Если нет, то можешь засунуть
свое чудное решение виртуального хостинга на bsd jail в соответствующее место.


anonymous
()
Ответ на: комментарий от anonymous

man seteuid уже прочитал? Понял, или опять со спущенными штанами
"бсдунов опускать" кинешься, а?

> Не спеши радоваться. 
Какую часть фразы "и впрямь интересное решение" тебе довести до
сознания? Я никоим образом не радуюсь и честно заинтересован
узнать про это решение поподробнее, особенно учитывая слова о
скором порте на FreeBSD и Solaris. Просто про jail, vserver,
chtrunk и freeVSD можно рассуждать с высокой степенью достоверности,
так как их исходники доступны для рассмотрения, про Virtuoso я такого
сказать не могу и соответственно оценок - ни отрицательных, ни
положительных - давать не берусь, тем более основываясь только
на той информации, что у них на сайте.

Для протокола - Qos для IP для jail делается тривиально, и на Linux
то же достигается не сложнее, это как мне кажется, selling point
Virtuoso не является. Гораздо более интересным является способность
пропорционального разделения процессорного времени. Потому решение и интересно и наверняка найдёт своего покупателя.

> Если нет, то можешь засунуть свое чудное решение виртуального
> хостинга на bsd jail в соответствующее место. 
Ты разницу между коммерческим продуктом и бесплатным решением 
улавливаешь? Ты согласен засунуть себе в "соответствующее место"
троицу vserver/chtrunk/freeVSD лишь на том основании, что
Virtuoso cуществует? Вместительное у тебя должно быть "место".

anonymous
()
Ответ на: комментарий от anonymous

> Только вот... нестабильная она больно... Кто, что это "она".

anonymous
()

А почему так скромно обошли вниманием user mode linux? Там тебе и по ip ограничить можно,
там и памяти сколько нужно выделишь виртуальному хосту, и вообще это настоящая вирт.машина
в отличие от всех прочих безделушек.

anonymous
()
Ответ на: комментарий от anonymous

По простой причине. Поплохеет машине от десятков или сотен копий user mode Linux. В отличие от {jail|vserver|chtrunk}.

anonymous
()
Ответ на: комментарий от anonymous

Ox-ox-ox! А от сотен(!) никем не сертифицированных рутов ей не поплохеет?
В том и прелесть виртуальных машин, что никто ни случайно, ни специально не сможет
занять все ресурсы, и вам не придется объяснять 99-ти рутам, почему их виртуальные хосты
перестали дышать. Допустим каждой виртуальной машине нужно минимум 64Mb. Помножим на сто.
Получим 6,4 гиг. Вполне реально. Нужно 4 гига настоящей памяти и столько же под своп.
Все сходится.

anonymous
()

А я использую FreeBSD и буду ее использовать, потому что там есть все что мне нужно и есть именно так как мне это нужно. в Линуксе вся настройка слишком просто и не понятно что и как делается - нет полного контроля над системой, а во FreeBSD есть (там я рукми правлю конфиги и точно знаю что мне нужно и что для этого нужно сделать в отличие от Линукса где все делается скриптами - хотите это или то или может быть все-таки это). И мне думается что со временем кто-то из линуксоидов перейдет (случалось такое) во FreeBSD и тогда он все поймет (что где и зачем), а насчет того чтобы кто-то перешел из FreeBSD в Линукс такого я не слышал.

anonymous
()
Ответ на: комментарий от anonymous

> в Линуксе вся настройка слишком просто и не понятно что и как делается
Дело привычки. Мне в линуксе все просто и понятно. И полный контроль над системой.

> в отличие от Линукса где все делается скриптами
Зависит от реализации. Можно (и я так делаю) все настраивать в конфигах.

> со временем кто-то из линуксоидов перейдет (случалось такое) во FreeBSD
Поздно доктор... История вспять не поворачивается. Она может только повторится на новом уровне.

anonymous
()

anonymous (*) (2001-12-12 12:41:40.0)

Мужиииииииииик.... :)))) Увааааажаааааааааюююю :) На самом деле фря отруливает всех и вся из линукс-сообщества. Одни порты/пакейджи чего стоят. А как ядро собирать приятно так это вообще тема отдельного треда.

anonymous
()

> Поздно доктор... История вспять не поворачивается. Она может только
> повторится на новом уровне.

Каждый божий день история "вспять" поворачивается, в чём нетрудно
убедиться, просто посмотрев архивы списков рассылки и Usenet.
Достали вопросы новообращённых из Linux в BSD camp класса "A где
найти HOWTO-xxx". Всё никак к наличию приличного man привыкнуть не
могут, сердешные :)

Ну да ничего, именно из бывших Linuxоидов и получаются со временем
довольно приличные участники BSD сommunity.

anonymous
()
Ответ на: комментарий от anonymous

> Нет ребята, я никогда не сменю swiss army knife (linux) на
> топор (bsd) ;)
Так ведь и не зовут. Про swiss army knife - это твоё личное мнение,
и право твоё на него священно. Только позволь заметить, что в
соответствии с _моими_ убеждениями и с моим _личным_ опытом -
бред вы несёте. Не нож, помойка скорее.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.