ZFS patches.

[Ivan Voras]

Antony Mawer wrote:
> Ivan Voras wrote:

>> I currently don't have high-end (4 CPU+) AMD64 machines to test, but 
>> with 1 CPU i386 virtual machine in VMWare, with 1 GB of memory, 
>> kmem_size=kmem_size_max=512M and no other tuning, with latest zpool 
>> format (11) it took about 15 minutes to get a "kmem_map too small" 
>> panic on a mixed load (buildkernel + blogbench + bonnie++).
>>
>> I've then tried the same load on the "real" hardware, 2 CPU, 2 GB 
>> memory, kmem_size=kmem_size_max=512M, and no other tuning, with the 
>> older zpool format (6) i get the same panic, though it takes about 
>> twice as long to happen.
> 
> Have you tried tuning arc_max and/or monitoring vmstat -m to see what is 
> happening? What does arc_max get auto-tuned to at the moment (ie. 
> without manually specifying)?
> 
> One of the things I recall reading that arc_max is more like a guide, as 
> some ZFS threads can exceed the max whilst other thread(s) go around 
> cleaning up and freeing memory once the limit is hit.
> 
> Maybe some better smarts are needed in auto-tuning arc_max so that it 
> leaves more of a buffer zone than it does at the moment...?

I think speculation in the same direction was discussed with the 
original port of ZFS - I don't know the details but if it arc_max could 
be better auto-tuned, I think it should be by now.

I'm more concerned about the "quiet period" before the panic. I notice 
ZFS threads have the same priority (PRI field in top) as userland 
threads (e.g. 44, 55...), while GEOM threads have it different (-8). I 
don't have the McCusicks book about it so I don't know how priorities 
whould work, but is this situation OK?

I will monitor vmstate -m if it will help Pawel. Should I?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080729/3fe9e39a/signature.pgp