#debian #zfs
#debian #zfs
Вопрос:
У меня есть небольшой домашний сервер, работающий с Debian Buster, где у меня есть файловая система ZFS ( ZFS: Loaded module v0.7.12-2 deb10u2, ZFS pool version 5000, ZFS filesystem version 5 ) с RAID.
Поскольку сервер иногда не используется в течение нескольких дней, я настроил скрипт автозапуска, который отключает сервер, если мои 2 больших жестких диска WD red находятся в режиме ожидания более 45 минут (не системный жесткий диск). Теперь я выяснил, что сервер больше не отключается, поскольку оба диска находятся в режиме ожидания всего несколько минут, прежде чем снова станут активными. Я протестировал iotop и выяснил, что ZFS с помощью команды txg_sync пробуждает их. Даже если никакой другой процесс ничего не записывает или не читает на дисках.
Я также проверил fatrace -c после перехода в каталог, в который смонтирован пул данных. В то время, когда команда txg_sync всплывает и пробуждает диски, вывод данных отсутствует. Обновление: похоже, что fatrace не работает должным образом с ZFS.
Теперь я использую iosnoop from и теперь знаю, что dm_crypt регулярно записывает данные на мои диски. Мои базовые диски зашифрованы с помощью LUKS.
./iosnoop -d 8,16
Tracing block I/O. Ctrl-C to end.
COMM PID TYPE DEV BLOCK BYTES LATms
dmcrypt_writ 1895 W 8,16 2080476248 4096 6516.10
dmcrypt_writ 1895 W 8,16 3334728264 4096 6516.14
dmcrypt_writ 1895 W 8,16 2080429048 16384 0.16
dmcrypt_writ 1895 W 8,16 3334728272 20480 0.21
dmcrypt_writ 1895 W 8,16 2080476256 20480 0.16
dmcrypt_writ 1895 W 8,16 3328225336 16384 0.20
В чем причина этого и как я могу предотвратить это?
Комментарии:
1. Теперь я понял, что сервер больше не отключается … Так что изменилось? Вероятно, что-то обращается к данным на этих дисках или обновляет их — простого открытия файлового дескриптора в файловой системе может быть достаточно, чтобы время доступа к индексу inode было обновлено, вызывая запись на диск.
2. Я не знаю. Это может быть связано с любым обновлением. Никаких других серьезных изменений не было сделано. Я не могу напрямую воспроизвести, когда это произошло в первый раз. Я отредактировал свой пост, поскольку теперь я даже проверил,
fatrace -cкоторый ничего не показывает во время пробуждения дисков.
Ответ №1:
https://github.com/openzfs/zfs/issues/8537#issuecomment-477361010
@niksfirefly если пул записывается, то вы должны ожидать, что поток txg_sync будет использовать процессор и ввод-вывод. Насколько это будет зависеть от вашего конкретного оборудования, конфигурации пула, какие функции / свойства включены, и вашей рабочей нагрузки. Это может быть нормальным для ваших обстоятельств.
И, возможно, эта ссылка тоже окажется полезной: https://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04
Как проверить использование дискового ввода-вывода для каждого процесса:
cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k 3
Этими полями являются PID, command и кумулятивные тики ожидания ввода-вывода. Это покажет ваши горячие процессы, но только в том случае, если они все еще запущены. (Вероятно, вы хотите игнорировать потоки журналирования файловой системы.)
Ответ №2:
Еще одно замечание по ZFS. Я работаю на Manjaro 20210101 с ядром 5.4, и в последние недели у меня была высокая нагрузка на txg_sync.
Согласно /var/log/pacman.log
[2020-12-31T08:58:24 0100] [ALPM] обновленные утилиты zfs (0.8.5-2 -> 2.0.0-2) [2020-12- 31T08:58:24 0100] [ALPM] обновленный linux54-zfs (0.8.5-10 -> 2.0.0-6)
С тех пор процесс txg_sync также восстановил спокойствие.
В Debian использование ZFS (и его версий), безусловно, решается несколько иначе.