From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Curt Sampson <cjs(at)cynic(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, GB Clark <postgres(at)vsservices(dot)com>, glenebob(at)nwlink(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Linux max on shared buffers? |
Date: | 2002-07-23 13:57:13 |
Message-ID: | 20020723235713.A2051@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Jul 23, 2002 at 07:52:56AM -0400, Jan Wieck wrote:
> Curt Sampson wrote:
> >
> > On Mon, 22 Jul 2002, Jan Wieck wrote:
> >
> > > I have some more wrinkles to iron out as well. We can hold blocks of
> > > hundreds of different files in our buffer cache without the need to keep
> > > an open file descriptor...
> >
> > As you can with mmap as well. The mapping remains after the file
> > descriptor is closed.
>
> 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?
My machine here is idling not doing much and the kernel is managing 53
processes with 223 open files currently caching some 52,000 blocks and 1140
mmap()ed areas. I'm sure if I actually did some work I could make that much
higher.
In short, if you have a machine capable of running 200 backends, I wouldn't
be surprised if the kernel wasn't already managing that kind of load.
Remember, brk() is really just a special kind of mmap().
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Zapczynski | 2002-07-23 14:01:58 | Exporting data from PostgreSQL 7.1 |
Previous Message | Nigel J. Andrews | 2002-07-23 13:43:29 | Re: [NOVICE] URGENT! pg_dump doesn't work! (fwd) |