Hello this is maybe off topic. Do you know memcached? We use it without postgresql six or seven months for short-live data with big success. regards Pavel Stehule 2009/9/22 Greg Spiegelberg <gspiegelberg@xxxxxxxxx>: > On Mon, Sep 21, 2009 at 5:39 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> > wrote: >> >> 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? >> > > I assume you intend to this or some variation of it. > mount -t tmpfs -o size=1G tmpfs /pgfast > > tmpfs file systems, including /dev/shm, ***should not*** be counted on as > being RAM only. File systems of this type in Linux, and at least Solaris > also, can be swap since the tmpfs type is derived from swap and swap = > memory + active swap partitions. > > I would think that a ram disk or ramfs may be more what you're after. Add > ramdisk_size=X, where X is the maximum size in kilobytes, to the kernel line > in your grub.conf file. Unlike tmpfs, the ramdisk_size X parameter cannot > be more than the memory of your server. When using a ramdisk the ext2 file > system would be best with all the fun noatime and like mount parameters. > This is good for a fast, volatile, fixed-size ramdisk. > > OTOH, ramfs can be just as fast but with all the fun system-hanging features > like growing until all RAM is consumed. > mount -t ramfs ramfs /pgfast > > Pro ... it will always be as fast, or possibly a hair faster, than tmpfs. > > Con ... it won't show up in a df output unlike tmpfs or ramdisk. Use the > mount command with no parameters to look for it and be sure to unmount it > when you're done. > > Pro/Con ... you can't specify the file system type like with ramdisk. > > Pro... it will only take away from memory as space is used, i.e. if you have > 500M of memory in use and mount the file system but do nothing else then > only 500M of memory is in use. If you then copy a 100M file to it then 600M > of memory is in use. Delete that 100M file and you're back to 500M of used > memory. > > Pro/Con ... unlike other file systems, it will grow with the need... > unchecked. It could attempt to consume all available memory pushing all > other processes out to swap and this is a bad, bad thing. > > > I'm sure there are other pro's & con's to ramfs. > > HTH. > > Greg > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
