From owner-freebsd-questions@FreeBSD.ORG Tue May 2 18:59:43 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8559916A90B for ; Tue, 2 May 2006 18:59:43 +0000 (UTC) (envelope-from nospam@mgedv.net) Received: from mgedv.at (mail.mgedv.at [195.3.87.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A9DC43D64 for ; Tue, 2 May 2006 18:59:39 +0000 (GMT) (envelope-from nospam@mgedv.net) Received: from metis (localhost [127.0.0.1]) by mgedv.at (SMTPServer) with ESMTP id C8BE4186864 for ; Tue, 2 May 2006 20:59:26 +0200 (MEST) From: "No@SPAM@mgEDV.net" To: Date: Tue, 2 May 2006 20:59:38 +0200 Message-ID: <002e01c66e1a$8fd083d0$dededede@avalon.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060502174604.GA91314@xor.obsecurity.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZuEMwitbr1krMLRtOng9K50abOsgABY7kQ Subject: RE: 6.1-RC2: strange kernel panic! X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nospam@mgedv.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 18:59:47 -0000 > Your kernel ran out of memory. Either you are using a workload that > is too heavy for your current settings, or there is a memory leak > somewhere in a kernel subsystem you are using. > Try to increase VM_KMEM_SIZE_MAX in your kernel, e.g. > options VM_KMEM_SIZE_MAX=524288000 #500MB > You may need to increase it further. i'm not sure, but probably this does not solve our problem. this system is used as a compilation host only (currently) and therefore there are no permanently running things like databases, huge daemons, etc... only ssh and syslog is up in userland. so the main question to me is, where the memory goes on this server, and how i can prevent this type of leak. (and even maybe help you fixin' it ;-) our current settings are (default in GENERIC): vm.kmem_size: 335544320 vm.kmem_size_max: 335544320 the compilation system uses a 350MB swap-based memory-disk for compilation, the whole disks are encrypted using GELI (AES256). network traffic is low (only ssh commandline stuff, no huge transfers). when i issued the "du -sk" the panic occurred. 5min ago, the system panic'd again, this time some more was logged: (originally, there have been >200 of these messages, numbers change, error=same) g_vfs_done():md0[WRITE(offset=346742784, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346750976, length=8192)]error = 28 g_vfs_done():md0[WRITE(offset=346761216, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346767360, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=346773504, length=6144)]error = 28 this time the panic occurred while transferring data from the hdd's to the md-device: panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated Uptime: 1h13m18s is there any way (which is suitable for a non-c-guru like me) how i can at least monitor, which statements cause the memory leaks? givin' it more memory could only raise the uptime, because at this time there are no permanently running processes except the os and ssh.