ru.unix.bsd

From: Alex Korchmar Dmitriy Smirnov wrote: DS> У кого какие мысли/практика? no user will ever ask you for ipv6. > Alex P.S. хотя колхоз-то тоже дело добровольное...

From: Alex Korchmar Eugene Grosbein wrote: AK>> это потому что у тебя половина памяти не используется под кэш. EG> Да, я ещё процессы запускаю и памяти им нужны нынче не килобайты, увы. ну вот беда в том, что в нормальных системах как-то принято не вручную выделять им страницы, а-ля ОС-РВ 1982. И оно, собственно, даже в ненормальной правильно работало - с пресловутыми патчами для memory pressure даже получалось запускать довольно прожорливые процессы, при полностью отданной под кэш оперативке когда они не запущены. А при compressed arc - make -j4 buildworld - гарантированно вис. > Alex

hi, All! а не поговорить ли нам о MTU и IPv6? Решил я субботне-воскресным вечером побаловаться с NPTV6, всё конечно транслирует, но обнаружил, что не всё оно транслирует, а именно ICMP PTB. Без трансляции хост ловит сообщение о слишком большом пакете, понижает мту и жизнь продолжается. Вот только не спрашивайте зачем что-то там транслировать, когда адресов вагон и тележка, вот захотелось время убить =) почитал всякие статейки о мировых тенденция и всё такое, если можно так выразиться. Основной смысл - не везде нативный в6, кто-то режет icmp, криво настроенный mss и всё в таком духе. Как я понимаю, путей соб-но два: играться с MTU и/или активировать PMTUD Blackhole Detection. Я пока что для себя решил остановиться на втором варианте и не трогать MTU, работает хреновина =) У кого какие мысли/практика? wbr, Dmitriy.

05 февр. 2022, суббота, в 23:30 NOVT, Alex Korchmar написал(а): AK>>> интересно, тот мервтый локап, который с ним связан, все еще с нами? EG>> Hи разу не встречал. AK> это потому что у тебя половина памяти не используется под кэш. Да, я ещё процессы запускаю и памяти им нужны нынче не килобайты, увы. Eugene

From: Alex Korchmar Eugene Grosbein wrote: AK>> интересно, тот мервтый локап, который с ним связан, все еще с нами? EG> Hи разу не встречал. это потому что у тебя половина памяти не используется под кэш. А при отсутствии искусственных ограничений - у меня ноут вис в 100 случаях из 100. К сожалению, разработчиков это совершенно не интересовало. > Alex

Hello *Dmitriy.* Saturday 05 February 2022 00:21, Dmitriy Smirnov wrote to Sergey Zabolotny: SZ>> в догонку про itldc - консоль вроде бы была и, кажется, даже SZ>> адекватно работала. проверить не могу т.к. не осталось там SZ>> виртуалок. DS> какой гипервизор? не смотрел DS> в общем домене тачка, т.е. широковещательный шум не достает? айпишник давали из /24, если я правильно помню. tcpdump-ом не смотрел, что творилось вокруг.

05 февр. 2022, суббота, в 09:16 NOVT, Alex Korchmar написал(а): EG>> vfs.zfs.compressed_arc_enabled="1" AK> интересно, тот мервтый локап, который с ним связан, все еще с нами? AK> (Вероятнее всего - да, если только не ушел из-за четного количества багов.) Hи разу не встречал. Впрочем, у меня не так много систем с ZFS, хотя они были разные, от 1GB RAM на разделе 5GB без избыточности, через 8GB с зеркалом на томах GRAID по 300GB, до 360GB RAM на RAIDZ1 в 18TB поверх GELI сырых дисках. Eugene

From: Alex Korchmar Eugene Grosbein wrote: EG> vfs.zfs.compressed_arc_enabled="1" интересно, тот мервтый локап, который с ним связан, все еще с нами? (Вероятнее всего - да, если только не ушел из-за четного количества багов.) > Alex

05 февр. 2022, суббота, в 11:24 NOVT, Eugene Grosbein написал(а): EG> Что касается кеша для zfs: EG> vfs.zfs.arc_max="100M" EG> vfs.zfs.vdev.cache.size="32M" EG> vfs.zfs.prefetch_disable="1" EG> vfs.zfs.vdev.trim_on_init="0" EG> vfs.zfs.compressed_arc_enabled="1" Ещё понадобилось: vfs.zfs.arc.meta_strategy=0 vfs.zfs.arc.meta_limit_percent=25 При дефолтном vfs.zfs.arc.meta_strategy=1 и малой памяти ядро начало жрать 100% CPU и хотя система и была по прежнему юзабельной и дисковые операции выполняла, но реактивность сильно уменьшилась, а при meta_strategy=0 быстро всё пришло в норму, за несколько секунд. При 1 было так в течение нескольких часов: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 0 root -8 - 0B 1056K - 213:45 63,46% kernel{arc_prune} 5 root 52 - 0B 624K RUN 132:07 36,17% zfskern{arc_evict} Eugene

05 февр. 2022, суббота, в 00:23 NOVT, Dmitriy Smirnov написал(а): DS> этим только хетцнер и подкупал +гиг оперативки, но лично для меня это не DS> существенных довод, так как не особо упераюсь в кэш для zfs. В 13.0-RELEASE под KVM обнаружилась проблема: работает нормально, но при ребуте виснет после успешной остановки сервисов и успешного сброса дисковых буферов, прямо в тот момент, когда уже должен быть собственно ребут. Оказалось, что проблема в timecounter: в HEAD в дополнение к обычным HPET, ACPI-fast и прочим добавили некий kvmclock, но это было уже после выпуска 13.0-RELEASE, так что туда оно не попало, зато попало в stable/13 и в stable/12, а заодно и в 12.3-RELEASE, который случился позже, так что в 12.3 этой проблемы нет. Обновился до 13.0-STABLE и проблема ушла. Что касается кеша для zfs: vfs.zfs.arc_max="100M" vfs.zfs.vdev.cache.size="32M" vfs.zfs.prefetch_disable="1" vfs.zfs.vdev.trim_on_init="0" vfs.zfs.compressed_arc_enabled="1" Eugene -- Поэты - страшные люди. У них все святое.