Тестирование BHyVe - FreeBSD Hypervisor

> Журнал не нужен, появляется geom_journal.

А потом SU-J...

А знаешь для чего нужен журнал? Чтобы БЫСТРО очистить диск от ставших ненужными после аварии питания зарезервированных перед записью, но незаписанных блоков данных!

Для UFS2 без журналя сия процедура очистки выполнялась в фоне с заметными тормозами для запущенных процессов, которые обращались к проверяемой в это время ФС. А после того, как внедрили возможность журналирования, от фонового процесса проверки целостности ФС и очистки можно отказаться — журналирование предполагает починку аварийно остановленной ФС на этапе ЗАГРУЗКИ, а не процессе работы.

Для Ext4 и всех остальных линуксовых файловых систем всё не так очевидно ДАЖЕ с журналированием — всё равно приходится делать профилактические проверки ФС примерно раз в месяц, если СПЕЦИАЛЬНО не отключить эту опцию fsck.

Для ZFS ещё веселее. Там scrub работает всё же незаметнее агрессивного fsck UFS2, и его можно штатно приостановить, а затем вновь запустить. Кроме того, ZFS — это CoW до мозга костей, так что scrub запускается ну в очень специфичных случаях, когда высока вероятность проблем с железом, и избыточность может упасть до нуля в любой момент.

iZEN (26.11.2011 20:51:05)

>> ни одна из ФС не умеет снапшоты

> В принципе, умеет любая фс с lvm.

dump/restore со снапшота LVM когда-нибудь делали? Только честно.

Как там откатить ФС на заранее созданный снапшот, потеряв те изменения, которые произошли с ФС после создания снапшота? Есть опыт отката?

> Гипервизор не нужен(У НАС ЕСТЬ jail!!111!),
> появляются попытки пилить XEN и онтопик.
> Тенденцию не замечаешь?

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

> Можно подумать, до появления ZFS, COW небыло как класса.

CoW — это техника упорядочивания данных в транзакции и транзакций, которые могут быть сохранены (подтверждены), а могут быть не сохранены (отклонены) безболезненно без потерь целостности и места для устройства хранения и ФС на нём. На линуксе CoW для ФС, пригодных к промышленному использованию, решается старым дедовским способом: журналирвоанием метаданных и, в особых случаях, данных. Так вот, для данных в линуксе никакой защиты CoW нет by-default.

> Вот только, кому нужен ZFS, не постесняется купить солярку.

Вот только "солярка" поддерживает далеко не тот большой спектр оборудования, который поддерживается Фри. Может так оказаться, что будешь сидеть без сетки (драйвера для новой сетевушки нет), с древним IDE HDD, в консоли (видеокарточка не поддерживается), зато с ZFSv15. :))

iZEN (26.11.2011 21:02:56)

Ты еще rsync предложи, только почитай, что из себя представляет master/master репликация.

kostian (26.11.2011 21:13:25)

ну есть же Xenocara :)

havelite (26.11.2011 22:30:08)

ну зачем так много про маздайную соляру!

havelite (26.11.2011 22:42:08)

>dump/restore со снапшота LVM когда-нибудь делали? Только честно.
Постоянно, публичное четвертование, к сожалению, карается законом.
Да и есть вполне ризонные юз кейсы.
>Я замечаю тенденцию попыток виртуализировать то, чему достаточно изолированных операционных окружений без накладных расходов.
Ok. Изоляция (os-level виртуализация) и пара/полная виртуализация, хоть иногда и пересекаются, но все же в реальном мире они есть две большие разницы.
С virtio дровами на сеть/io оверхедом можно почти пренебречь.
>Вот только "солярка" поддерживает далеко не тот большой спектр оборудования, который поддерживается Фри. Может так оказаться, что будешь сидеть без сетки (драйвера для новой сетевушки нет), с древним IDE HDD, в консоли (видеокарточка не поддерживается), зато с ZFSv15. :))
Когда у меня был временный фетиш на солярку, я даже на домашнюю файлопомойку купил 82574L т.к. встроенный BCM5722 не поддерживался.
Сферическое оборудование в вакууме - это гора цвет металла.
Если для решения конкретной задачи нужна солярка, внезапно появится соответствующее железо.
>А знаешь для чего нужен журнал?
>bla bla bla
Я примерно представляю, как работают СУ и журнал. ... so?
>проверки ФС примерно раз в месяц
Как и регулярно скрабить зфс пулы.
>scrub запускается ну в очень специфичных случаях.
tellmemoar.жпг

kostian (27.11.2011 2:31:37)

> А для разработки приложений под тот же ведроид лучше ставить линукс.

А мужики то не знают! Какие же преимущества открываются славному разработчику приложений под андроид при использовании linux? Менее отзывчивый по сравнению с оффтопиком eclipse?

cobold (27.11.2011 13:30:02)

Ахтунг! Вантузятник в треде!!!!

havelite (27.11.2011 15:41:36)

> pf работает в один поток на одном ядре процессора. Зачем вы думаете мы(как и другие) покупаем многоядерные процессоры и карточки ET, чисто чтобы улучшать благосостояние фирмы интел?

Скажите это двум моим 8-миядерникам. Они страшно удивятся.

> То что где то что то работает _иногда_ - это конечно круто.

24x7

sergv (27.11.2011 18:07:35)

>Вот только "солярка" поддерживает далеко не тот большой спектр оборудования, который поддерживается Фри
>в консоли (видеокарточка не поддерживается)

Аж прослезился от смеха. Разбуди когда фря будет поддерживать Intel HD3000.

madgnu (27.11.2011 19:13:48)

> pf работает в один поток на одном ядре процессора...

Уточняю: pf работает ровно на столько потоков, на сколько работает netisr.

Мои боевые сервера (FreeBSD 7.4 + патч на netisr имени AlterX) имеют по 8 ядер и по два сетевых адаптера. В одном случае это bge (с патчами от Игоря Сысоева для увеличения количества пакетов за прерывание, т.к. у меня серверный вариант), во втором - igb со стоковым драйвером (+немного потюненые настройки параметров сетевой).

Стоит mpd5 + pf. Проблемы бывают раз в полгода. И то это связано с глюками freeradius. Решается перезагрузкой mpd5 и фиксами на таблицу.

Дык вот, более новый сервер жует >1000 сессий одновременно. С фильтрацией на таблицах (которые динамически перестраиваются). Поток пакетов при этом >60 kpps на обоих сетевых в обе стороны. (Т.е. >60kpps input + > 60kpps output на каждой).

Теперь мое утверждение еще раз: УМВР. ЧЯДН?

sergv (27.11.2011 20:02:18)

Я боюсь удивить ваши восьмиядерники, но суммарный рейт:

1059.24 Mb/s In  1076.09 Mb/s Out - 181677.3 p/s In  182601.5 p/s Out

model name : Pentium(R) Dual-Core CPU E6800 @ 3.33GHz + два порта 82576

Терминация пппое и нат разнесены на разные машины по архитектурным соображениям и 60 килопакетов оно делает вполне без натуги. И главное раз в пол года не случается никаких проблем, и фичи accel-ppp позволяют снимать нагрузку с сервера незаметно для юзеров(ну то есть нам не нужно резко рвать их сесии чтобы обновить чего то или почистить вентиляторы).

Вот тут http://www.openbsd.org/faq/pf/ru/perf.html написано буквально следующее:

Есть какие то подтверждения что pf таки может работать на многих процессорах(с большей производительностью чем на одном)?

ventilator (27.11.2011 22:04:42)

> Я боюсь удивить ваши восьмиядерники, но суммарный рейт: ...

М-м-м. Да на моих нагрузка покамест на процессоры только 40%, при суммарном потоке (две карты) в 120 kpps :-)

Но: на Pentium(R) Dual-Core CPU E6800 @ 3.33GHz 180 kpps - это круто. Надо посмотреть на альтернативу. Особенно если шейперы можно налету менять.

А про PF на OpenBSD сайте можно пока забыть. В опенке просто нет многопоточного netisr. Как и избавления от giant lock.

А подтверждение того, что pf может работать на многих процессорах: у меня работает. Если по сети пошукаете, то у многих других - тоже.

sergv (28.11.2011 6:25:01)

каюсь, о учитель, второго мастера не приметил, только вот в таком случае самому неплохо было бы почитать об этом, потому как непонятно чем тот же mysql на линуксе от фришного или солярного отличается...
кстати, обосновать можешь, чем зеркало как реплика плохо/не подходит?

EvgGad_303 (28.11.2011 13:57:21)

Мускул то причем?
Имелась ввиду блочная репликация с шаред фс, именно сетевое зеркало.

kostian (28.11.2011 15:57:37)

Я пока не заметил что у вас работает - никаких подтверждений этому нет, особенно учитывая что 120килопакетов это 40% 8 ядер ксеона(как я понял). То что вы в топе видите нагруженные несколько ядер - это не значит что пф работает в _один момент времени_ на нескольких сразу. Вообще не исключено что то на одном то на другом (что кстати уменьшает производительность из за непопаданий в кеш). В сети как раз не видно ни одного упоминания что pf работает многопоточно, более того авторы PF пишут что он спроектирован однопоточным - можете изучить nag.ru на предмет этого.

PS: у меня нат и терминация/шейпинг на разных машинах, однако процессорной мощности в сумме меньше вашего.

ventilator (28.11.2011 17:12:47)

$ top -bSP -d 3
...

last pid: 54720; load averages: 0.01, 0.02, 0.00 up 52+00:54:43 08:17:26
120 processes: 9 running, 76 sleeping, 35 waiting
CPU 0: 0.0% user, 0.0% nice, 0.0% system, 7.5% interrupt, 92.5% idle
CPU 1: 0.0% user, 0.0% nice, 0.0% system, 6.4% interrupt, 93.6% idle
CPU 2: 0.0% user, 0.0% nice, 0.8% system, 7.5% interrupt, 91.7% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 7.5% interrupt, 92.5% idle
CPU 4: 0.0% user, 0.0% nice, 0.0% system, 4.1% interrupt, 95.9% idle
CPU 5: 0.0% user, 0.0% nice, 0.0% system, 9.8% interrupt, 90.2% idle
CPU 6: 0.0% user, 0.0% nice, 0.8% system, 6.4% interrupt, 92.9% idle
CPU 7: 0.0% user, 0.0% nice, 0.8% system, 9.0% interrupt, 90.2% idle
Mem: 35M Active, 504M Inact, 492M Wired, 36K Cache, 822M Buf, 6797M Free
Swap: 8300M Total, 8300M Free

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
14 root 1 171 ki31 0K 16K CPU4 4 1137.1 100.00% idle: cpu4
15 root 1 171 ki31 0K 16K CPU3 3 959.8H 98.19% idle: cpu3
16 root 1 171 ki31 0K 16K CPU2 2 954.9H 98.00% idle: cpu2
12 root 1 171 ki31 0K 16K CPU6 6 960.9H 94.68% idle: cpu6
17 root 1 171 ki31 0K 16K CPU1 1 1013.9 94.29% idle: cpu1
13 root 1 171 ki31 0K 16K CPU5 5 959.7H 93.90% idle: cpu5
11 root 1 171 ki31 0K 16K CPU7 7 959.1H 93.16% idle: cpu7
18 root 1 171 ki31 0K 16K RUN 0 860.2H 90.19% idle: cpu0
26 root 1 -44 - 0K 16K WAIT 5 266.5H 6.49% swi1: net5
23 root 1 -44 - 0K 16K WAIT 6 265.3H 6.30% swi1: net2
22 root 1 -44 - 0K 16K WAIT 0 266.3H 6.15% swi1: net1
27 root 1 -44 - 0K 16K WAIT 0 266.2H 6.15% swi1: net6
21 root 1 -44 - 0K 16K WAIT 2 264.8H 6.15% swi1: net0
24 root 1 -44 - 0K 16K WAIT 4 266.5H 6.05% swi1: net3
25 root 1 -44 - 0K 16K WAIT 7 265.2H 5.96% swi1: net4
54 root 1 -68 - 0K 16K WAIT 1 149.6H 5.37% irq257: igb0
58 root 1 -68 - 0K 16K WAIT 4 53.3H 1.76% irq260: igb1
53 root 1 -68 - 0K 16K WAIT 0 24.0H 0.68% irq256: igb0

И подобная картина во все моменты времени. До оптимизации правил PF все было грустнее - на net[0-6] уходило втрое больше ресурсов.

sergv (29.11.2011 6:21:19)

Забыл добавить - сейчас оно бездельничает (~10 kpps In/Out на обоих интерфейсах).

Uptime маленький - таймзону менял.

sergv (29.11.2011 6:34:09)

Еще продолжу: Код pf под FreeBSD сильно отличается от кода для OpenBSD. Он насыщен lock/unlock для того, чтобы мог нормально работать на SMP.

sergv (29.11.2011 9:16:13)

Можно какие то пруфы по поводу многопоточности pf наконец то? А то у вас ~8% загрузки каждого ядра на 10килопакетах(!!) - и вы утверждаете что все работает быстро. В тоже время народу c nag.ru вообще ничего не известно о многопоточности pf и с него переходят на линуксовые наты как раз потому что однопоточен. Может вы знаете что-то чего не знаем мы? Какие процессоры у вас?

ventilator (29.11.2011 13:01:53)

Нагрузка нелинейно зависит от количества пакетов:

$ netstat -I igb0 1
input (igb0) output
packets errs bytes packets errs bytes colls
29583 0 17983626 31520 0 24342832 0
31041 0 18735862 32079 0 25611007 0
31012 0 19409307 30694 0 23969878 0
30924 0 19406257 30236 0 23294659 0
30136 0 17761412 30464 0 24326547 0
^С

Соответственно, есть еще и вторая карта с обратным траффиком.

$ top -b -d 3|grep CPU:|tail -1
CPU: 0.1% user, 0.0% nice, 0.8% system, 23.5% interrupt, 75.6% idle

Процессоры (две штуки): CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

Про nat врать не буду. СКОРЕЕ всего NAT НЕ многопоточный.

На сервере только терминация PPPoE + фильтры. Это раскладывает нагрузку с одного ядра на несколько в (почти) линейной зависимости.

sergv (29.11.2011 14:33:15)

У меня на пппое терминации, примерно те же цифры получаются, но на говножелезе: Pentium(R) Dual-Core CPU E6600 @ 3.06GHz

Только пппое+шейпинг u32 hash +немного фильтров для редиректа юзеров без денег на веб заглушку.

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

ventilator (29.11.2011 14:59:59)

Дык тем-же и занимается!

Настроено не то что "по канонам". "По канонам" оно из-за тормозов на "не anchor-нуто-табличном" pf.conf жрало в 3 раза больше процессора + netisr однопоточный. Оно эти 30 килопакетов еле пережовывало.

Видимо, таки PF + ng_car "сливает".

Буду думать, смотреть на accel-ppp. Я не фанатик. Просто мне отсутствие революций во FreeBSD на серверах уж шибко нравится.

sergv (29.11.2011 15:09:50)

в pf.conf выкручиваете лимиты(по числу стейтов и времени их жизни, чтобы держались подольше), берете в руки pktgen(это ядерный генератор трафика в ядре linux) ну или любой другой быстрый генератор.
И шлёте из сети 10/8 пакетики. У меня был nat. Вообщем, где-то при 200-300 тыс стейтов pf "захлёбывается" и машина перестаёт форвардить трафик(при жалких 30-50kpps). Тестилось на quad core и em с драйверами яндекса. Карточка умеет несколько аппаратных очередей.

stateful вообще выключил нафиг - не нужен он для терминатора...

Вобщем, не надо меня агитировать - текущие серваки пусть так помрут (один свой гигабит ДОЛЖЕН вытянуть, а у второго broadcom принципиально на мелких пакетах не сможет).

А вот дальше - посмотрю в сторону развертывания на arch/debian.

sergv (29.11.2011 17:44:36)

В плане производительности ipfw+dummynet выгоднее чем pf+ng_car. По канонам - это как раз mpd+ipfw tablearg+dummynet. Но тогда конечно не так красиво получится с mpd - ведь в случае с ng_car он прям по радиусу получает циферки и списки префиксов для шейпинга, а так придется скриптики городить. Как раз такую связку я в свое время поменял на linux+rp-pppoe, а затем и на accel-pppd по причине падений фри.

ventilator (30.11.2011 4:54:12)

Не знаю какой у вас броадком, но вроде как netxtream2 не хуже интела.

ventilator (30.11.2011 4:57:28)

BCM5722 - прерывание на 64 пакета.

Для сравнения во втором (igb) - прерывание на 4096 пакетов.

sergv (30.11.2011 7:03:11)

> Разбуди когда фря будет поддерживать Intel HD3000.

А что, не поддерживает? В кору валится при наличии устройства под названием "Intel HD 3000"?

Знаешь что, попроси лучше Intel написать драйвер под Xorg так, чтобы он поддерживал свою работу не только в одном лишь Linux, но и хотя бы в FreeBSD, не говоря уж о других свободных операционных системах.

P.S. У меня на компе ничего никогда от Intel не будет. Сыт по горло уже их "совершенно новыми технологиями".

iZEN (30.11.2011 20:16:25)

Не поддерживает. Только vesa, что эквивалентно полному отсутствию поддержки.

В солярке, кстати, работает, так что претензии не к интелу, а к разработчикам некроОС.

madgnu (30.11.2011 20:53:42)