перезагрузка после паники ядра отключена ?

Да: root@S04:~# cat /proc/sys/kernel/panic 0

Да: root@S04:~# cat /proc/sys/kernel/panic 0

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

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

Не объясняет, почему при уменьшении количества запущенных нод перезагрузки становятся реже (и даже совсем пропадают при количестве нод примерно менее половины). Не говоря о том, что аптайм до апгрейда был несколько месяцев в полной загрузке. И вообще исходный вопрос был: чем так интенсивно занимаются arc_prune и arc_evict при primarycache=none на всех датасетах и как этого избежать.

Не объясняет, почему при уменьшении количества запущенных нод перезагрузки становятся реже (и даже совсем пропадают при количестве нод примерно менее половины). Не говоря о том, что аптайм до апгрейда был несколько месяцев в полной загрузке. И вообще исходный вопрос был: чем так интенсивно занимаются arc_prune и arc_evict при primarycache=none на всех датасетах и как этого избежать.

ну сделайте даунгрейд и надейтесь что нагрузка станет меньше.

Как вариант открыть issue на Гите

https://github.com/openzfs/zfs/pull/17065

Тут спрашивали почему использовать кэш плохо

Так вот

ZFS игнорирует ошибки flush (потому что изначально не предназначено, что они будут ему поступать)

ну сделайте даунгрейд и надейтесь что нагрузка станет меньше.

Нагрузка от storj не уменьшится. А иногда будет и увеличиваться (было уже так несколько месяцев назад когда разработчики проводили нагрузочное тестирование). Вопрос в том, как заставить zfs не пытаться при этом всё в кэш упихивать, даже если мне это не требуется (когда от storj идут массовые загрузки для долгого хранения)

Нагрузка от storj не уменьшится. А иногда будет и увеличиваться (было уже так несколько месяцев назад когда разработчики проводили нагрузочное тестирование). Вопрос в том, как заставить zfs не пытаться при этом всё в кэш упихивать, даже если мне это не требуется (когда от storj идут массовые загрузки для долгого хранения)

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

Arc Вам наоборот снижает нагрузку ввода-вывода на диски...

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

Примерно так делаю. Вот сейчас аптайм 6 часов уже, осталось 10 нод из 60 запустить. Сейчас процессы arc по 40-50% отжирают. При критическом увеличении начнутся перезагрузки, поэтому постепенно добавляю

Arc Вам наоборот снижает нагрузку ввода-вывода на диски...

Для storj? Ну-у-у...

Arc Вам наоборот снижает нагрузку ввода-вывода на диски...

Этого я разумом не понимаю. Storj читает то, что давным давно записал. Загрузку дисков он не уменьшит. А вот процессор перегружает

Каждый раз, когда идет обращение на чтение к диску, zfs проверяет есть ли запрашиваемые данные в arc. Если есть, то они из arc берутся, с диска не читается.

Если данные пишутся на диск, то они тоже попадают в arc.

Данные из arc "вымываются" по хитрому алгоритму. Если данные часто запрашиваются, то они "живут" в arc долго.

Данные из arc "вымываются" по хитрому алгоритму. Если данные часто запрашиваются, то они "живут" в arc долго.

Одно и то же два раза не запрашивается. Это ведь как бекап. Вот сделали вы бекап, зачем его в памяти хранить, пока вам восстановление из бекапа не потребуется? А вот эти процессы непрерывного "вымывания", как видно, процессор перегружают

если есть память zfs ее использует. Она "не знает", что у Вас за данные: бэкап или виртуалки....

если есть память zfs ее использует. Она "не знает", что у Вас за данные: бэкап или виртуалки....

Память мне не жалко. Пусть использует. Но когда она процессор этим вымыванием насилует до зависаний/перезагрузки - мне хочется это отключить. Но не получается

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

у Вас случаем не gzip-9 сжатие настроено?

у меня была ситуация на паре серверов на дисках samsung 860 pro. Диски замирают, на них не возможно что-либо записать, считать. iowaite под 100%, система висит, кроме zabbix

у Вас случаем не gzip-9 сжатие настроено?

lz4

это быстрый метод сжатия, быстрее только lzo, но он сжимает очень просто и быстро

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

Вот сейчас чем эти два процесса занимаются? Это пока не насилуют. Но когда до 80-90% доходит - начинаются аварийные перезагрузки

Вот сейчас чем эти два процесса занимаются? Это пока не насилуют. Но когда до 80-90% доходит - начинаются аварийные перезагрузки

Георгий вроде выше отвечал

Вообще, поставь metadata only и дай ему хотя бы гигов 16

не знаю, я бы вернул настройки в значения по-умолчанию. Затем отключил бы все пулы. Убедился, что эти процессы не занимают проц. (что с оборудованием и ос все в порядке.) Затем подключал бы каждый пул и смотрел на каком будет проявляться симптом.

Вообще, поставь metadata only и дай ему хотя бы гигов 16

Да я даже none ставил - никакого толку. Память он сейчас по дефолту (как Георгий рекомендовал) 32 взял

Да я даже none ставил - никакого толку. Память он сейчас по дефолту (как Георгий рекомендовал) 32 взял

Поставь metadata

не знаю, я бы вернул настройки в значения по-умолчанию. Затем отключил бы все пулы. Убедился, что эти процессы не занимают проц. (что с оборудованием и ос все в порядке.) Затем подключал бы каждый пул и смотрел на каком будет проявляться симптом.

Так и сделал. Но там не на конкретном пуле проявляется, а постепенно на количестве

если не интересно разобраться, то можно все снести, переустановить Ос, zfs, пересоздать пулы и наблюдать. Если будут проблемы, то это железо...

если не интересно разобраться, то можно все снести, переустановить Ос, zfs, пересоздать пулы и наблюдать. Если будут проблемы, то это железо...

Либо баг zfs

Никак не отменяет это

только на одной ноде?

Поставь metadata

Делал тоже. Перед тем как совсем до none дошел

только на одной ноде?

Как я понял только на одной, которую обновили до свежей версии

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

только на одной ноде?

Нет, там не от конкретной ноды проблема, а от их общего количества.

Вы вроде писали, что у Вас несколько таких серверов? Или я путаю?

у Вас ядро 6.12... по умолчанию стоит 6.1.0...

Как я понял только на одной, которую обновили до свежей версии

Нет, контейнеры нод вообще автоматически обновляются довольно часто. Я там по другим причинам общий upgrade сделал. Сейчас склоняюсь к тому, что не само обновление виновато, а факт одновременногоо запуска всех нод после обновления. У них в самом начале более интенсивная работа с диском, чем в "крейсерском" режиме. Надеюсь, если без перезагрузки сейчас обойдется плавное подключение - то потом снова будет многомесячный крейсерский режим

это ядро находится в backports

Вы вроде писали, что у Вас несколько таких серверов? Или я путаю?

Да, 4 сервера и 2 десктопа. Все на днях обновил одновременно

Вы вручную установили ядро из backports?

Вы вручную установили ядро из backports?

всё автоматом. backports прописан в источниках.

Да, 4 сервера и 2 десктопа. Все на днях обновил одновременно

а проблема проявляется на одном, ели я правильно понял?

а проблема проявляется на одном, ели я правильно понял?

да Возможно, потому что на других дисков и нод меньше

нет из backports нужно вручную ядро поставить

какие ядра на остальных серверах?

нет из backports нужно вручную ядро поставить

На этом сервере (в отличие от остальных) непосредственно после апгрейда появилось сообщение The ZFS modules cannot be auto-loaded. Try running 'modprobe zfs' as root to manually load them. что я и сделал. Остальное - upgrade автоматом

А, вот еще было E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem. Что тоже сделал руками

если сомневаетесь, что правильно скомпелировались модули zfs, то можно их перекомпелировать: dpkg-reconfigure zfs-dkms update-initramfs -u -k all update-grub reboot

но это мало вероятно...

а что с версией ядра на остальных серверах?

какие ядра на остальных серверах?

Посмотрю попозже. Хотя вот что: Остальные я не перегружал - значит, у них сейчас покажет старое ядро ведь? А перегружать сейчас я уже не рискну, чтобы не спровоцировать такие же проблемы, как на этом

посмотрите какие ядра: ls -l /boot

текущее ядро uname -a

На этом сервере (в отличие от остальных) непосредственно после апгрейда появилось сообщение The ZFS modules cannot be auto-loaded. Try running 'modprobe zfs' as root to manually load them. что я и сделал. Остальное - upgrade автоматом

А, это кое-что проясняет

Найти бы только эту ситуацию, у меня была такая на arm бордах после обновления ядра. Обычно это значит, что у тебя криво ядро/хедеры встали и dkms не смог нормально собрать

посмотрите какие ядра: ls -l /boot

На остальных серверах всё гораздо старше. Где-то 6.1, а где-то даже 5.10. Сейчас вспоминаю: На днях то я везде только автоматом обнавлялся, а на этом сервере несколько месяцев назад, действительно, вручную собирал. В связи с другой проблемой, связанной со storj.

По умолчанию ядро для debian12.9 6.1.0

Это может не сильно важно, но стоит наверное привести к стандарту

Это может не сильно важно, но стоит наверное привести к стандарту

Пока попробую вытащить (без перезагрузок) эту конфигурацию. Вот 20 минут назад запустил еще 3 ноды, а вместо роста нагрузки CPU arc тем временем освободил его. Возможно, ранее запущенные ноды в "крейсерский режим" переходят/ PS iowait, кстати, по-прежнему высокий: 77%

Здорово всем. Ну вот и наступил у меня полный кринж. pool читаемый, но txg_sync просто фризится.

так уже полчаса

[Ср фев 19 13:15:35 2025] INFO: task zfs:7334 blocked for more than 1087 seconds. [Ср фев 19 13:15:35 2025] Tainted: P IOE 6.1.0-31-amd64 #1 Debian 6.1.128-1 [Ср фев 19 13:15:35 2025] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [Ср фев 19 13:15:35 2025] task:zfs state:D stack:0 pid:7334 ppid:1 flags:0x00004002 [Ср фев 19 13:15:35 2025] Call Trace: [Ср фев 19 13:15:35 2025] <TASK> [Ср фев 19 13:15:35 2025] __schedule+0x34d/0x9e0 [Ср фев 19 13:15:35 2025] schedule+0x5a/0xd0 [Ср фев 19 13:15:35 2025] io_schedule+0x42/0x70 [Ср фев 19 13:15:35 2025] cv_wait_common+0xaa/0x130 [spl] [Ср фев 19 13:15:35 2025] ? cpuusage_read+0x10/0x10 [Ср фев 19 13:15:35 2025] txg_wait_synced_impl+0xcb/0x110 [zfs] [Ср фев 19 13:15:35 2025] txg_wait_synced+0xc/0x40 [zfs] [Ср фев 19 13:15:35 2025] zil_replay+0x103/0x140 [zfs] [Ср фев 19 13:15:35 2025] zfsvfs_setup+0x204/0x240 [zfs] [Ср фев 19 13:15:35 2025] zfs_domount+0x425/0x570 [zfs] [Ср фев 19 13:15:35 2025] ? register_shrinker_prepared+0x35/0x70 [Ср фев 19 13:15:35 2025] ? mutex_lock+0xe/0x30 [Ср фев 19 13:15:35 2025] zpl_mount+0x16d/0x1d0 [zfs] [Ср фев 19 13:15:35 2025] legacy_get_tree+0x27/0x50 [Ср фев 19 13:15:35 2025] vfs_get_tree+0x25/0xc0 [Ср фев 19 13:15:35 2025] path_mount+0x47a/0xa90 [Ср фев 19 13:15:35 2025] __x64_sys_mount+0x116/0x150 [Ср фев 19 13:15:35 2025] do_syscall_64+0x55/0xb0 [Ср фев 19 13:15:35 2025] ? set_shrinker_bit+0x29/0x60 [Ср фев 19 13:15:35 2025] ? list_lru_add+0xf0/0x1a0 [Ср фев 19 13:15:35 2025] ? _copy_to_user+0x21/0x30 [Ср фев 19 13:15:35 2025] ? cp_new_stat+0x135/0x170 [Ср фев 19 13:15:35 2025] ? __rseq_handle_notify_resume+0xa9/0x4a0 [Ср фев 19 13:15:35 2025] ? __do_sys_newfstatat+0x4e/0x80 [Ср фев 19 13:15:35 2025] ? switch_fpu_return+0x4c/0xd0 [Ср фев 19 13:15:35 2025] ? exit_to_user_mode_prepare+0x14b/0x1e0 [Ср фев 19 13:15:35 2025] ? syscall_exit_to_user_mode+0x1e/0x40 [Ср фев 19 13:15:35 2025] ? do_syscall_64+0x61/0xb0 [Ср фев 19 13:15:35 2025] ? exit_to_user_mode_prepare+0x40/0x1e0 [Ср фев 19 13:15:35 2025] ? syscall_exit_to_user_mode+0x1e/0x40 [Ср фев 19 13:15:35 2025] ? do_syscall_64+0x61/0xb0 [Ср фев 19 13:15:35 2025] ? exit_to_user_mode_prepare+0x40/0x1e0 [Ср фев 19 13:15:35 2025] ? syscall_exit_to_user_mode+0x1e/0x40 [Ср фев 19 13:15:35 2025] ? do_syscall_64+0x61/0xb0 [Ср фев 19 13:15:35 2025] ? do_user_addr_fault+0x1b0/0x550 [Ср фев 19 13:15:35 2025] ? exit_to_user_mode_prepare+0x40/0x1e0 [Ср фев 19 13:15:35 2025] entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Такие вот сюрпризы^^

Идет resilvering вообще. Заменяю два диска на ssd из массива на 4х RAIDZ2

памяти вроде хватает

И вот чешу репу, а че делать то?

У меня фишка в том, что на моей матери многие диски постоянно меняют буквы.

И еще проблема в том, что zfs собака такая грузится ДО networking. Я в import.service поставил грузится перед самбой. Надеюсь в случае перезагрузки оно загрузится. Если честно это полная шляпа которую не понятно кто так сделал, ведь это же тупо грузить импорт ДО появления управления.

И еще проблема в том, что zfs собака такая грузится ДО networking. Я в import.service поставил грузится перед самбой. Надеюсь в случае перезагрузки оно загрузится. Если честно это полная шляпа которую не понятно кто так сделал, ведь это же тупо грузить импорт ДО появления управления.

Самба к ZFS не имеет никакого отношения

Я загружен сейчас из рековер

Самба к ZFS не имеет никакого отношения

Я про очередность загрузки

И еще проблема в том, что zfs собака такая грузится ДО networking. Я в import.service поставил грузится перед самбой. Надеюсь в случае перезагрузки оно загрузится. Если честно это полная шляпа которую не понятно кто так сделал, ведь это же тупо грузить импорт ДО появления управления.

Логично, потому что сперва надо импортнуть пулы

Ты же корень ФС не грузишь после сети?