@nuclight не либы исключено раздуто слишком (и разбиратся в них лень даже в libev ;D)

не говоря уже про libevent

бгагага

для каждого по 7-8 штук

для каждого чего?

с таким походом ничего хорошего ты точно не напишешь =)

мне маны читать некогда, я программист (с) бессмертная цитата Вингородова в R.U.B

@nuclight ну я не говорю про что-то большое поэтому не вижу смысла в либах :/

для каждого чего?

ок, еще раз про сценарий. есть список файлов и по нему в несколько потоков бежит процесс-читатель. и для каждого сетапа(bcache vs l2arc) читатель запускался по 7-8 раз

ок, еще раз про сценарий. есть список файлов и по нему в несколько потоков бежит процесс-читатель. и для каждого сетапа(bcache vs l2arc) читатель запускался по 7-8 раз

есть численные результаты для каждого прогона? не было ли тренда в какую-либо сторону? ну и ради интереса, прогон для разогрева участвовал в усреднении или выбрасывался?

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

при хитах в 1.5 раза выше, слишком подозрительно, чтобы всё чтение занимало больше времени разница в хитах ведь не небольшая, а целых 1.5 раза ну и, я надеюсь, основной объём данных не на другом ссд или супербыстром (сопоставимом с ссд) массиве лежал? :}

@Krond а как насчет libev?

те же яйца, только легковеснее

не помню, есть ли там обертка буферизации

https://stackoverflow.com/questions/9433864/whats-the-difference-between-libev-and-libevent

Грубо говоря libevent это набор готовых примитивов типа HTTP сервер/DNS сервер и т.п., а libev это исключительно eventloop.

Если нужен только eventloop — libev лучше так как там он аккуратнее выписан и имеет больше возможностей, если же нужно готовое решение — libevent.

есть численные результаты для каждого прогона? не было ли тренда в какую-либо сторону? ну и ради интереса, прогон для разогрева участвовал в усреднении или выбрасывался?

не учавствовал. там после 2 прогонов уже была устоявшаяся картина.

при хитах в 1.5 раза выше, слишком подозрительно, чтобы всё чтение занимало больше времени разница в хитах ведь не небольшая, а целых 1.5 раза ну и, я надеюсь, основной объём данных не на другом ссд или супербыстром (сопоставимом с ссд) массиве лежал? :}

основной объем данных был на обычном sata hdd

основной объем данных был на обычном sata hdd

т.е. в случае с bcache - 10% данных поднялось из кэша, а в случае с l2arc - 15% и при этом чтение через l2arc заняло больше времени фантастика какая-то

Чтобы узнать revision number своего мира и ядра я открываю /usr/src/Makefile и читаю "$FreeBSD: releng/11.1/Makefile 317565 2017-04-28 17:57:07Z bdrewery $" То есть моя ревизия r317565? Тут просто появляестя кое какая ясность с моими проблемами с перезапуском клеток. В частности вот https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219251#c2 походу был запилен патч в head/sys/netpfil/pf/pf.c и чтобы воспроизвести проблему и убедиться что всё ок мне придётся перепрыгнуть на STABLE?

Сжелай бэкпорт

Странно что такую очевидную штуку нельзя посмотреть скажем через uname или freebsd-version

Сжелай бэкпорт

одного только этого файла?

одного только этого файла?

Да

Одного коммита

uname -a выдает ревизизию

11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #1: Mon Oct 16 15:39:55 MSK 2017

выдаёт только patch level

хотя вот на одной старой тачке у меня так: 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r268512: Thu Jul 10 23:44:39 UTC 2014

выдаёт только patch level

потому что это релиз

а не стейбл

Но релиз разве не на основе какой-то ревизии сделан? Типа всё что до 317565 это 11.0 всё что после 11.1. Почему бы не впихнуть 317565 хоть куда-то как доп инфу

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

Чтобы узнать revision number своего мира и ядра я открываю /usr/src/Makefile и читаю "$FreeBSD: releng/11.1/Makefile 317565 2017-04-28 17:57:07Z bdrewery $" То есть моя ревизия r317565? Тут просто появляестя кое какая ясность с моими проблемами с перезапуском клеток. В частности вот https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219251#c2 походу был запилен патч в head/sys/netpfil/pf/pf.c и чтобы воспроизвести проблему и убедиться что всё ок мне придётся перепрыгнуть на STABLE?

не надо так делать freebsd-version -ku или uname -a как сказали выше

два раза -ku!

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

кто работал с kqueue? наслышан что лучше epoll'а

про epoll тут можно почитать: https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/

ролик про очереди, зачётный :)

https://twitter.com/ed_maste/status/922823575555284994

Вах, вах, вах https://twitter.com/OpenZFSonLinux/status/922883536281096192

https://twitter.com/michaeldexter/status/922924137105956865

скинул в винчятик

пусть порадуются

коварный какой :)

Free BSOD

Такое и раньше вроде было :DD

ну так, стабильность признак мастерства

про epoll тут можно почитать: https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/

практически все решения описанных болей мне пришли сразу. тот же SO_REUSEPORT. а kqueue лишен этих проблем?

kqueue имеет более красивый дизайн и не требует костылей которые к тому же были добавлены не очень давно. Но учитывая что мало кто работает с epoll/kqueue напрямую (без оберток типа libevent/libev и т. п.) все это имеет второстепенное значение.

kqueue имеет более красивый дизайн и не требует костылей которые к тому же были добавлены не очень давно. Но учитывая что мало кто работает с epoll/kqueue напрямую (без оберток типа libevent/libev и т. п.) все это имеет второстепенное значение.

ну я про ситуацию, когда у тебя в 1 дескриптор регнут в нескольких kqueue?

имеется в виду проблема thundering herd? во фре она не решена. Но надо иметь ввиду что она актульна когда у тебя есть сотни или хотя бы десятки процессов (поэтому в апаче есть accept mutex).

практически все решения описанных болей мне пришли сразу. тот же SO_REUSEPORT. а kqueue лишен этих проблем?

во фре в таком виде как в линуксе REUSEPORT нету (но есть в dragonfly AFAIK). Кстати последний пост в этом блоге про то, что использование REUSEPORT в nginx приводит к увеличению задержек.

имеется в виду проблема thundering herd? во фре она не решена. Но надо иметь ввиду что она актульна когда у тебя есть сотни или хотя бы десятки процессов (поэтому в апаче есть accept mutex).

бха. да тот же kqueue + пачка тредов по числу ядер на более-менее современном сервере с парой сокетов.

а там еще вылезет numa и прочие чудеса локальности

ERROR: S client not available

бха. да тот же kqueue + пачка тредов по числу ядер на более-менее современном сервере с парой сокетов.

будет интересно если кто то проведет бенчмарк, показывающий что просыпание например 32 процессов (или сколько там ядер на типичном современном сервере) на каждый accept плохо влияет на производительность системы.

во фре в таком виде как в линуксе REUSEPORT нету (но есть в dragonfly AFAIK). Кстати последний пост в этом блоге про то, что использование REUSEPORT в nginx приводит к увеличению задержек.

ну там вполне понятный кейс: " If a single cashier gets blocked,  all the traffic waiting in its queue will stall. The maximum latency will grow if any single queue gets stuck."

т.к. у нас нет обратной связи по скорости обработки каждным воркером, то мы насыпаем всем примерно поровну.

будет интересно если кто то проведет бенчмарк, показывающий что просыпание например 32 процессов (или сколько там ядер на типичном современном сервере) на каждый accept плохо влияет на производительность системы.

8 физических ядер на более-менее современном cpu. *2(из-за ht) и еще *2 из-за пары сокетов.

Я на всякий случай подписался - вдруг гдето проблема с freebsd будет

Хм, оно лучше lz4? Мне казалось lz4 всех рвет

lz4 быстрее, lz4hc хуже и медленно жмёт, но быстрее распаковывает.

http://fastcompression.blogspot.com/2015/01/zstd-stronger-compression-algorithm.html

https://twitter.com/michaeldexter/status/923229178555637761

Привет всем. Кто нибудь пользовал selenium на фри?

кто нибудь поди да пользовался

Хей, хей, потише, мы записываем :) https://twitter.com/allanjude/status/923246595037995008

Эко их торкает https://www.freebsdfoundation.org/blog/openzfs-raid-z-online-expansion-project-announcement/

подскажите как портмтастером восстановить из бекапа порт?

а зачем портмастером? они же в /var/cache/pkg все лежат, если не очищал

т.е. просто через pkg их установить?

удалить более новый, установить более старый - все через pkg

спасибо

О, шустрики, уже выложили за первый день https://livestream.com/accounts/26168990/OpenZFS2017

https://www.youtube.com/watch?v=ZF8V7Tc9G28 мне нравится подход к презентации, надо применить :)

О как https://twitter.com/ocochardlabbe/status/923892016626503680

Неплохо

Добрый день. Подскажите пожалуйста, как монтировать автоматом zfs? что сделать вместо ручного zfs mount -a ? совсем тупой

Добрый день. Подскажите пожалуйста, как монтировать автоматом zfs? что сделать вместо ручного zfs mount -a ? совсем тупой

/etc/fstab

я думал есть другие варианты