EG>> В последнее время я даже на дешевых виртуалках с UFS и i386 AK> памяти, памяти у дешевых виртуалок сколько?
1G
EG>> стал выделять 5G под раздел, отданный ZFS, чтобы включить там компрессию EG>> lz4 и положить туда src, obj и ports. AK> 1.4G /usr/obj AK> 1.2G /usr/src AK> 2.5G /usr/ports AK> и где профит? Те же 5G.
Hу, положим, в один раздел 5G у тебя это бы не влезло, а у меня в такой раздел с учетом компрессии влезет 10G с небольшим запасом.
AK> но дешевые виртуалки обычно сильнее всего ограничены именно памятью, а AK> совсем дешевые - еще и процессором (точнее, он просто платный per hz)
С платным CPU я не беру - я не настолько богат, чтобы покупать такое.
AK> zfs, кстати, уже умеет хотя бы не вызывать катастрофы если этой самой памяти AK> чуток не хватило?
It depends. Hа девятке всё было прекрасно - лимит на ARC в общем работал, превышение на несколько процентов сверх 40M ненадолго не в счет.
После обновления до 10.3 оказалось, что ARC-лимит в очередной раз не работает и ZFS легко может переполнить дефолтный лимит на kmem в i386, после чего системе настают кранты до резета; пока стабилизировал это через /boot/loader.conf:
vm.kmem_size="768M" vm.kmem_size_max="768M"
Оно там у меня совсем немножко за 512M вылазит при обходе дерева командой svn update. Думаю, починят. Можно попробовать на 11.0 перелезть, там не страшно.
Плюс в /usr/src/UPDATING есть рекомендация для i386 поднять размер стека ядерных тредов с дефолтных 2 страниц до 4, потому как код ZFS очень любит кушать стек, а переполнение стека в ядерном треде это гарантированный panic("double fault").
9.3/i386 с рекомендованными KSTACK_PAGES=4 и двумя гигабайтами виртуального адресного пространства ядру вместо одного (KVA_PAGES=512) и vm.kmem_size="512M" вела себя очень стабильно с ZFS.
Eugene -- Поэты - страшные люди. У них все святое. --- slrn/1.0.2 (FreeBSD) * Origin: RDTC JSC (2:5006/1@fidonet)
