On Fri, 12 May 2006, Iasen Kostov wrote:
Exactly what i did :). I set vm.pmap.shpgperproc=600 in loader.conf and
about 5 min after boot the system paniced and I was not able even to see
the message (either because I was pressing enter for the command or it
just doesn't wait for a key). Then i set it to 500 in loader at boot
time and currently it works but when it crashed used PV entries were ~4
300 000 now they go to ~5 000 000 and it doesn't panic. Which make me
think that the panic is not related to setting vm.pmap.shpgperproc to
600 (which could probably lead to KVA exhastion) but to something else.
I'll try to increase KVA_PAGES (why isn't there tunable ?) and then set
vm.pmap.shpgperproc to some higher value, but this will be after a fresh
make world (I cvsuped already :( ) some time soon.
Can you provide instructions on how to create a testbench that exhibits
these same problems? Can eAccelerator + PHP + Apache + some simple script
+ apachebench do the trick?
If so, that would allow other people to work on the problem. Kris
Kennaway seems to like benchmarking; maybe you could pry him temporarily
away from MySQL benchmarking to take a look at this.
Also note that Peter Wemm has been reducing the size of PV Entries in
-current, as he was running out of KVA due to them too - maybe he could
provide you with a patch for 6.x with the same feature. Here's part of
his description of the change:
---
This is important because of the following scenario. If you have a 1GB
file (262144 pages) mmap()ed into 50 processes, that requires 13 million
pv entries. At 24 bytes per pv entry, that is 314MB of ram and kvm, while
at 12 bytes it is 157MB. A 157MB saving is significant.
---
HTH,
Mike "Silby" Silbersack
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
