* Scott Marlowe <scott.marlowe@xxxxxxxxx> [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@xxxxxxxxxxx command like a king, http://www.highrise.ca/ work like a slave.
Attachment:
signature.asc
Description: Digital signature
