*** Alex Kicelew [2018-01-17 23:13]: >Поэтому может кто-нибудь (возможно, Sergey Matveev:) >знает, можно ли как-нибудь понять, за каким чертом он минут 5-15 читает >диск.
Ух, даже не знаю что тут сказать. Вообще не могу предположить что именно ZFS мог бы делать. В фоне на долго ZFS обычно может делать только три вещи, как правило: scrub, resilver и destroy (когда async_destroy включен). На чтение из них только scrub работает. Но ARC сам по себе не будет просто так брать и освобождаться -- аналогично кэшу обычной ФС (cached поле в top/free). ARC уменьшиться в размерах только если какое-то приложение хочет памяти больше чем осталось -- тогда его вытесняют. ZFS может тупить например на секунды, допустим десятки секунд -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется что это кто-то сторонний что-то начинает делать. Я не мало работал на системах с 4, 8 и 16 GB памяти и везде с HDD. 4 GB отличаются только тем, что по-умолчанию отключен read prefetch (но он ничего не может сделать чтобы система на минуты уходила "тупить"). Нагрузки были самые разные: и sequential read/write больших файлов и PostgreSQL с десятками GB БД и MongoDB которые упирались в IOPS диска. Но везде FreeBSD/HardenedBSD. Так что может быть это какие-то косяки в Linux реализации? Хотя коллега с GNU/Linux говорит что у него на 4 GB с HDD ни разу ничего похожего на ваше поведение не встречалось. Но мне кажется что это не в ZFS дело, раз размер ARC уменьшается -- его значит кто-то другой вытесняет. Можно попробовать например кэшировать только метаинформацию в ARC, возможно только для заданных dataset-ов, выставив zfs set primarycache=metadata. Не исключено что data регулярно вытесняет metadata и диск вынужден снова и снова лезть за ней на диск. Но это мысли в слух. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
