Re: тормоза ZFS
*** 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
Reply to: