Re: session servers in ram

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: session servers in ram
Date: 2009-09-22 13:16:44
Message-ID: 20090922131643.GC3742@oak.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

* Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> [090921 19:39]:
> I'm looking at running session servers in ram. All the data is
> throw-away data, so my plan is to have a copy of the empty db on the
> hard drive ready to go, and have a script that just copies it into ram
> and starts the db there. We're currently IO write bound with
> fsync=off using a 15k5 seagate SAS drive, so I'm hoping that moving
> the db into /dev/shm will help quite a bit here.
>
> Does anybody any real world experience here or any words of sage
> advice before I go off and start testing this?

*If* fsync=off is really meaning that there are no sync commands
happening on your pg partitions (and nothing else, like syslog, is
causing syncs on them), and you're kernel is tuned to allow the maximum
dirty buffers/life, then I'm not sure that's going to gain you
anything... If your pg processes are blocked writing, with no syncs,
then they are blocked because the kernel has no more buffers available
for buffering the writes...

Moving your backing store from a disk-based FS to disk-based swap is only
going to shift the route of being forced to hit the disk...

Of course, details matter, and results trump theory, so test it ;-)

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alan McKay 2009-09-22 13:19:44 Re: statement stats extra load?
Previous Message Pavel Stehule 2009-09-22 13:05:43 Re: session servers in ram