Date: Tue, 2 May 2006 20:59:38 +0200 From: "No@SPAM@mgEDV.net" <nospam@mgedv.net> To: <freebsd-questions@freebsd.org> Subject: RE: 6.1-RC2: strange kernel panic! Message-ID: <002e01c66e1a$8fd083d0$dededede@avalon.lan> In-Reply-To: <20060502174604.GA91314@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002e01c66e1a$8fd083d0$dededede>