Re: тормоза ZFS
On 01/18/18 12:37, Sergey Matveev wrote: > вытесняют. ZFS может тупить например на секунды, допустим десятки секунд > -- сбрасывая буферы TXG на диски, но тут нет речи о минутах. Мне кажется > что это кто-то сторонний что-то начинает делать. Спасибо. Буду очень внимательно думать в эту сторону. Собственно, то, что это проделки ZFS, я предположил из-за того, что в такие моменты в iotop лидируют именно его процессы (хотя и не только они, но остальные каждый раз разные, а они всегда), о чем забыл упомянуть сразу. Тем не менее, раз такое поведение только у меня, значит, буду искать.
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
тормоза ZFS
Hi. Вообще он работает хорошо. Но иногда на домашнем ноуте с 8 гигами памяти и крутящимся (не SSD) диском он начинает сильно тормозить. Гарантированно -- когда я начинаю работать за ноутом после долгого перерыва, с утра или после работы. Непериодически, но регулярно -- в процессе работы. 0-1 раз по вечерам, 2-5 раз по выходным. Длятся тормоза минут 5-15, потом проходят. Судя по индикаторам, в это время происходит сильное чтение (именно чтение, не запись) с диска (в обычных условиях dstat рапортует уровень чтения 100-500k (затрудняюсь сказать, за какой период он меряет), в ситуации тормозов иногда 2-5M, а иногда и 10-13), LA тоже вырастает до 10-15. Если это происходит в начале работы после долгого перерыва, то при этом уменьшается (иногда раза в 4) размер ARC -- видимо, освобождает память под новые условия работы. Если в середине работы, то никаких закономерностей я не заметил -- размер ARC может уменьшаться, может увеличиваться, может оставаться прежним, своп может заполняться, может освобождаться, может не трогаться. От количества свободной памяти тоже практически не зависит -- в результате тормозов она может как уменьшаться, так и увеличиваться. От установленного размера ARC тоже, я играл с разными вариантами, но тормоза возникают все равно и примерно с равной регулярностью. Очевидно, в общем это нехватка памяти -- на других машинах, где по 16Г, такого не наблюдается. Но, к сожалению, увеличить память на ноуте возможности нет. Поэтому может кто-нибудь (возможно, Sergey Matveev:) знает, можно ли как-нибудь понять, за каким чертом он минут 5-15 читает диск. А если понять, то может, получится как-то добиться и уменьшения тормозов. Хотя бы понять, куда смотреть в это время -- в /proc/spl/kstat/zfs/* я смотреть пытался (как в обычные, так и в пиковые моменты), но никаких закономерностей не уловил.
