Re: Linux max on shared buffers?
От | Curt Sampson |
---|---|
Тема | Re: Linux max on shared buffers? |
Дата | |
Msg-id | Pine.NEB.4.44.0207240906060.497-100000@angelic.cynic.net обсуждение исходный текст |
Ответ на | Re: Linux max on shared buffers? (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Linux max on shared buffers?
|
Список | pgsql-general |
On Tue, 23 Jul 2002, Jan Wieck wrote: > No resource limit on that? So my 200 backends all map some random > 16,000 blocks from 400 files and the kernel jiggles with it like > it's never did anything else? Do you know how much of your process is already mmaped in exactly this way? If you take a look at the source code for ld.so, you'll likely find that all of the shared libraries your executable is using are mapped in to your process space with mmap. And in fact, it's all mmap under the hood as well; the kernel is effectively internal calls to mmap to map the executable and ld.so into memory in the first place. On BSD systems, at least, but probably others, all of the shared memory is just an anonymous (i.e., using swap space as the backing store) bunch of mmapped pages. So in theory, having several hundred processes each with a gigabyte or two of mmaped 8K blocks is not going to be a problem. However, I've not tested this in practice (though I will do so one day) so that's not to say it won't fail on certain OSes. In that case you'd want to map much smaller amounts, and live with the extra syscall overhead. But even so, it would still be far more efficient than copying blocks into and out of shared memory. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC
В списке pgsql-general по дате отправления: