snott wrote:
Trust me, I really do want 250GB (or more) of swap. I'm using swap as a
backing store for an HTTP reverse proxy for very large cache sets. Its more
efficient to just use the vm layer for LRU object management than to create
a huge mmap'd file with file buf caching.
I am not certain but I think on 64-bit systems the 32GB limitation is
per swap device (on i386 there is a 16GB total limitation because of a
32-bit counter of 512 byte blocks), so you can add multiple swap
devices. However if you slice up a disk into many partitions you might
lose performance because it will try to round robin between them,
assuming they are independent (but they're not; you'll lose I/O
throughput from seek delays). It may not be hard to change this behaviour.
In general your strategy is a good one but there are other problems;
managing that amount of swap will require a lot of auxiliary kernel
memory. It is hard to estimate exactly how much for various reasons
(it's not entirely deterministic), but in my environment even 20GB of
swap requires increasing
kern.maxswzone=209715200
i.e. about 200MB of memory just to keep track of the allocated swap. If
you don't tune this then you'll run out of "swap zone" when you allocate
beyond a certain point, and the kernel will deadlock. I think the
default value allows about 8GB of swap use.
Other kernel limits will prevent this from being raised above about
1500MB (although a forthcoming change in 8.0 will bring it up to 4GB).
Basically, even though there are valid reasons to want to do what you're
doing (and I do it myself on the build cluster that builds the FreeBSD
packages), you're operating in a zone that would have been considered
complete insanity until recently, and sufficiently few people have
wanted to try that no-one has thought about optimizing in this regime.
I think it would be quite an interesting project to try, though.
Kris
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
