Date: Thu, 21 Jan 2010 10:34:13 -0800 From: Matthew Jacob <mj@feral.com> To: freebsd-fs@freebsd.org Subject: Re: Repeatable ZFS "kmem map too small" panic on 8.0-STABLE Message-ID: <4B589E25.3010608@feral.com> In-Reply-To: <4B58976E.1020402@polands.org> References: <4B58976E.1020402@polands.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Can you get a stack traceback? > Hello, > > I've got an 8.0-STABLE (amd64) box with 4GB RAM. The machine is > running off a 6-disk RAIDZ1 booting from GPT. The box consistently > panics on unixbench's fsdisk program. > > I have been gathering some metrics in an attempt to isolate the > parameters that are significant, but I admit I do not really > understand all the relationships. At this point, I have nothing set > in /boot/loader.conf > > Here are some of the values I was recording within seconds of the panic: > > # dmesg | grep memory > real memory = 4294967296 (4096 MB) > avail memory = 3961372672 (3777 MB) > > kstat.zfs.misc.arcstats.size: 308522248 > vfs.zfs.arc_max: 829480960 > vfs.zfs.arc_meta_limit: 207370240 > vfs.zfs.arc_meta_used: 165575944 > vfs.zfs.arc_min: 103685120 > vm.kmem_size: 1327169536 > vm.kmem_size_max: 329853485875 > > # vmstat -m | egrep 'InUse|solaris' > Type InUse MemUse HighUse > solaris 491349 1316172K - > > % zpool status > pool: bethesda > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > bethesda ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/disk0 ONLINE 0 0 0 > gpt/disk1 ONLINE 0 0 0 > gpt/disk2 ONLINE 0 0 0 > gpt/disk3 ONLINE 0 0 0 > gpt/disk4 ONLINE 0 0 0 > gpt/disk5 ONLINE 0 0 0 > > errors: No known data errors > > My concern is if I can panic the box with a simple file system > benchmark, what will happen when I rysnc files across a 1GB LAN > connection? I am very willing to run any number of tests and tweek > ZFS as necessary. Please advise. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B589E25.3010608>