Kris Kennaway wrote: > Darren Reed wrote: >> Kris Kennaway wrote: >>> ... >>> Well yes, that is one hypothesis, but the evidence points elsewhere >>> as well. Prior the change you reference, some of my zfs machines >>> would run for weeks before hitting a load pattern that exhausted >>> their kmem_map and triggered the panic. Also unless I have missed >>> it I am not seeing the sudden flood of panic reports that may >>> indicate sudden breakage. It is quite possible that this particular >>> report has nothing to do with the recent change. >> >> Indeed. >> >> But here's something else to ponder... >> >> I've been using ZFS since it was internal beta at Sun, at first on >> i386 and later on amd64. >> I've never run into this kind of panic on Solaris. System can get >> very slow, yes, with >> ZFS hogging lots of memory, but it never panic'd because of it. >> >> We need to come up with a strategy here to solve this problem, be it >> fixing the kmem >> virtual memory or fixing zfs. > > Yes, Solaris does something architecturally different because it is > apparently acceptable for zfs to use gigabytes of memory by default. Well, if you were designing a file system for servers, is there any reason that you wouldn't try to use all of the RAM available? A similar thought process goes into having a unified buffer cache that uses all the free RAM that it can (on a 1.5GB NetBSD box, 1.4GB is file cache.) Even if I'm running a desktop workstation, if I'm not there, there's no reason that ZFS shouldn't be able to encourage the OS to swap out all of the applications (well as much as can be) if it so desires. The problem comes in deciding how strong ZFS's hold should be and how to apply pressure from other parts of the system that want to use the RAM as well. Now given that we have a ZFS tuning guide, surely the question we need to ask ourselves is why can't we take the recommendations from that and make up some code to implement the trends discussed? And how do we measure how much memory ZFS is using? DarrenReceived on Wed Sep 26 2007 - 08:01:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC