[freebsd] ZFS, TMPFS, pagedaemon/uma и подземный стук

Anton Sayetsky vsasjason at gmail.com
Sat May 6 22:20:46 EEST 2017


6 мая 2017 г., 20:13 пользователь Slawa Olhovchenkov <slw at zxy.spb.ru> написал:
> 2netch: а какого я не получил это письмо через рассылку?
> только копию в личную почту?
>
> On Sat, May 06, 2017 at 06:40:06PM +0300, Anton Sayetsky wrote:
>
>> 6 мая 2017 г., 18:15 пользователь Slawa Olhovchenkov <slw at zxy.spb.ru> написал:
>> > On Sat, May 06, 2017 at 05:52:06PM +0300, Anton Sayetsky wrote:
>> >
>> >> Приветствую, товарищи.
>> >>
>> >> Имеется сервер с 256 GiB оперативы, который с помощью nginx раздаёт
>> >
>> > 0. надеюсь не через sendfile? только aio можно применять.
>> Естественно, aio. sendfile на этой железке вообще никогда не включался.
>
> в loader.conf загрузка aio не показана, generic aio не содержит, ты
> вообще молчишь.
Да как бы с конфигом ведра и/или модулями проблем нет - вот и не
посчитал необходимым сразу это добавлять. Но, естественно, готов
предоставить дополнительную инфу, которая может быть полезна для
разбирательств.

>> >> файлы по HTTP, и я наблюдаю весьма интересный эффект, который
>> >> проявляется только при выполнении определённых действий и только после
>> >> того, как ARC впервые вырастает до максимального объёма. При
>> >> совпадении этих условий процесс pagedaemon/uma начинает вытеснять ARC.
>> >> После достижения минимального значения через короткое время (от
>> >> мгновенно до ~10 минут) происходит залипание всех процессов (но чаще
>> >> всего, кроме nginx) в состоянии D. И, конечно же, всё это происходит
>> >> без каких-либо сообщений об ошибках.
>> >> Провоцируется так:
>> >> 1. Попытка сборки в TMPFS devel/m4 - залипает на "checking dup2"
>> >> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207303)
>> >> 2. Попытка сборки в TMPFS lang/gcc - залипает на tar, который
>> >> выполняется в конце, перед созданием пакета
>> >> 3. tar cf - /usr/ports | xz ... (/usr/ports для примера, на других
>> >> каталогах также залипает)
>> >> Также при попытке сборки некоторых портов появляются странные ошибки
>> >> "нет файла" при копировании в $STAGEDIR, при это те же порты
>> >> собираются в poudriere, но иногда без тех самых файлов, которые не
>> >> были найдены на хосте.
>> >>
>> >> Версия системы:
>> >> root at cs0:~# freebsd-version -ku
>> >> 10.3-RELEASE-p14
>> >> 10.3-RELEASE-p18
>> >
>> > 1. Перейди на 11-STABLE
>> > 2. Примени https://reviews.freebsd.org/D7538 и отпишись о результатах
>> > туда.
>> К сожалению, этот вариант неприменим. Правила таковы, что на
>> "нетестовых" серваках стоит -RELEASE. Да и хватило мне обновления с 9,
>> на которой подобной проблемы не было.
>
> Ну страдай, если тебе так хочется.
Как писал ранее - проявляется только в строго определённых ситуациях
(кстати, сюда make -j 26 build{world|kernel} не входит, несмотря на
невозможность сборки некоторых портов), так что вряд ли есть
страдания. Скорее некоторое жжение от того, что при обновлении
приходится ещё и сессию на IPMI держать...

>> >> /boot/loader.conf такой:
>> >> autoboot_delay="4"
>> >> loader_logo="beastie"
>> >> kern.geom.label.disk_ident.enable="0"
>> >> kern.geom.label.gptid.enable="0"
>> >> kern.ipc.nmbclusters="0"
>> >> zfs_load="YES"
>> >> vfs.zfs.arc_min="192G"
>> > 3. эту убери
>> Поставлено для 2 целей:
>> 1. Чтобы быстрее падало.
>> 2. Чтобы кэш таки не "опускался слишком низко", ибо больше там память
>> занять нечем.
>
> А я не спрашиваю зачем ты это поставил, я говорю что надо сделать.
В отличие от тебя, я не столь силён в коде ZFS/vm, чтобы предлагать
свои патчи, однако не думаю, что это избавляет от необходимости хоть
какой-то аргументации совета по изменению настроек.
Возможно, моё намерение протестить без использования UMA - глупость,
но для изменения arc_min не вижу никаких причин. Отрицательных
эффектов от установки такого значения не имеется. Положительный
имеется - если рядом работает клиент NFS, его кэши не вымывают ARC
полностью. Ну и наличие этой настройки на сабж не влияет - и с
дефолтным ограничением размера ARC снизу точно так же залипало всё,
только через более длительное время.


More information about the freebsd mailing list