From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 16:20:14 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 110B6106566B for ; Mon, 6 Dec 2010 16:20:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F3C578FC15 for ; Mon, 6 Dec 2010 16:20:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB6GKDFM094153 for ; Mon, 6 Dec 2010 16:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB6GKD3r094152; Mon, 6 Dec 2010 16:20:13 GMT (envelope-from gnats) Date: Mon, 6 Dec 2010 16:20:13 GMT Message-Id: <201012061620.oB6GKD3r094152@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: amd64/145654: amd64-curent memory leak in kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 16:20:14 -0000 The following reply was made to PR amd64/145654; it has been noted by GNATS. From: Andriy Gapon To: Andrey Smagin , bug-followup@freebsd.org Cc: Subject: Re: amd64/145654: amd64-curent memory leak in kernel Date: Mon, 06 Dec 2010 18:16:30 +0200 on 05/12/2010 22:47 Andrey Smagin said the following: >> Is still reproducible? >> How much RAM do you have? What panic message is printed when this happens? >> This could be a KVA exhaustion or fragmentation issue related to ZFS. > > I have 4G of RAM, panic messages about malloc memory for network subsystem. > After opening PR was some commit helped decrease memory usage under heavy > load. I use last night CURRENT right now. Next loader.conf now avoiding this problem: > > vfs.zfs.arc_max="300M" - larger size increase performance but also increase possibility of panic So you can still reproduce the panic with CURRENT? Can you get panic message and stack trace? > vfs.zfs.vdev.cache.size="16M" > vfs.zfs.cache_flush_disable="0" > vfs.zfs.prefetch_disable="0" > > vfs.zfs.zfetch.array_rd_sz="4M" > vfs.zfs.zfetch.block_cap="256" > vfs.zfs.zfetch.min_sec_reap="2" > vfs.zfs.zfetch.max_streams="16" > > vm.kmem_size="4G" > > IMHO gigantic problem is - ZFS use "wired" memory instead "inactive" as UFS. That's the way ZFS is. -- Andriy Gapon