Date: Fri, 22 Aug 1997 23:03:42 +0200 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: gordon@drogon.net Cc: hackers@FreeBSD.ORG Subject: Re: Problems with > 256MB of RAM Message-ID: <199708222103.XAA08591@pat.idi.ntnu.no> In-Reply-To: Your message of "Fri, 22 Aug 1997 18:33:33 %2B0100 (BST)" References: <Pine.LNX.3.95.970822181529.7369B-100000@unicorn>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'm running FreeBSD 2.2-STABLE on a machine with 384MB of RAM. (will be > upgraded to 512MB soon). I'm having problems running named with very large > zone files. The machine panics and reboots. A 'top' running on the machine > at the time shows: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 1418 root 105 0 235M 236M RUN 8:16 97.01% 97.01% named > > It's always after it's allocated 235MB. > > The panic message is always: > > panic: get_pv_entry: cannot get a pv_entry_t There are two main reasons for this type of panic 1. temporary shortage of free physical memory (cf PR#2431). Use sysctl to increase limits of reserved free physical memory, reducing the probability for running out of free memory. sysctl -w vm.v_free_reserved=1024 sysctl -w vm.v_free_min=1500 2. permanent shortage of virtual memory allocated for pv entries. Increase the size of allocated virtual memory for pv entries by adding: options "PMAP_SHPGPERPROC=400" to the kernel config file. For most users, the default value of 200 is big enough. I use 800. > The kernel has had 3 patches supplied by David Greenman <dg@root.com>, > modifying files > > /src/sys/i386/conf/Makefile.i386 > /src/sys/i386/include/pmap.h > /src/sys/i386/include/vmparam.h > > The only other bits that have been modified in the kernel config file > (apart from deleting unused drivers, etc.) are: > > maxusers 32 > options "MAXMEM=393216" # 384MB > options "NMBCLUSTERS=2048" > > options "MAXDSIZ=402653184" # 384MB > options "DFLDSIZ=402653184" # 384MB > > BOUNCE_BUFFERS are commented out. > > Heres the catch: If I run a program that grabs all available memory in 1MB > chunks (and writes to it as it grabs it), then exits (380MB later), then I > can run named and it grows up to full size happily. (I'm running named > 8.1.1, but I see the same with 4.9.6-REL). This indicates that you probably have a temporary shortage of free physical memory. This occur during fork() of big processes. RES 236 MB -> 59000 pv entries needed -> 404 free physical pages needed. --> use a higher value, e.g. 1024 for vm.v_free_reserved - Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708222103.XAA08591>