At 7:47 PM +0100 3/10/07, Martijn van Oosterhout wrote:
On Sat, Mar 10, 2007 at 08:30:20AM -0500, Dan Sugalski wrote:
Possibly it won't. The machine the DB is on sees heavy access to
large files, to the point where parts of the database may get flushed
out of the OS buffer cache. I was working on the (possibly deeply
flawed assumption) that I'd be better off if more of the database was
guaranteed pinned in memory in Postgres' buffer cache -- it wouldn't
Err, is shared memory actually guarenteed to be pinned in memory? I
mean, in Linux it's not as that is a form of DOS attack, pin all memory
by allocating it as SHM.
I'm not worried about swapping -- the box has more than enough memory
that it's not going to swap.

What I am looking at is response times after a relatively long (20-30
minute) period of inactivity. When the database is being accessed and
the data files are either in shared buffers or OS file cache,
performance is really snappy. When the database has been ignored for
a while and other things go on the box, postgres' data files get
expunged from the OS caches, and access times for the first few
queries go from milliseconds to seconds. No surprise, certainly, HD
access times being what they are.

I've got enough memory on the box that I can reasonably map a four
or five gig into postgres and just leave it there. It'll probably not
slow down anything else significantly, but if it means the difference
between having to re-read a page from disk and just hit shared
buffers, then it's worth it in response time.
--
Dan

--------------------------------------it's like this-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 5 | next ›
Discussion Overview
grouppgsql-general @
categoriespostgresql
postedMar 10, '07 at 4:55a
activeMar 10, '07 at 9:16p
posts5
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2019 Grokbase