> On Jun 16, 2011, at 20:43, Greg Smith wrote: >> The layout you proposed (OS+WAL , data) might be effective, but if your >> write volume is low it may not be much of an improvement at all over a >> simple RAID1 of two drives. The odds that you are going to correctly >> lay out individual sections of a disk array with only two pairs to >> spread the data across aren't good. If this is all you have to work >> with, a 4-disk RAID10 would at least guarantee you're taking advantage >> of all four drives. With that controller, it should be almost twice as >> fast in all cases as hooking up only two drives. > > The data is more or less constantly rewritten (it contains hourly updated > travel related data). Therefore, I really tend to buy 4 disks from the > start on. Just make sure you have a Battery-backed-write cache or flash backed, so you can set it safely to "write-back". >> There is another possibility I would suggest you consider. You could >> buy the server with a single pair of drives now, then wait to see what >> performance is like before filling the other two slots. It is far >> easier to figure out what drive technology makes sense if you have >> measurements from an existing system to guide that decision. And you >> may be able to get newer drives from your vendor that slide into the >> empty slots. You may not ever even need more than a single RAID-1 pair. >> I see lots of people waste money on drives that would be better spent >> on RAM. > > Actually, there are already two older servers in place right now. The data > is about 14GB in size and slowly rising. Considering the price for RAM I > can easily afford to install more RAM than the db data is in size. I was > aiming for 24GB. But even then, I cannot be sure that no queries will read > from the disk. AFAIK, there is no way to force all the data to stay in > cache (shared_buffers for example). tar cf - $PGDATA > /dev/null in cron every now and then /15-30 minutes) would certainly do the trick . not pretty but we're solving problems not talking about beauty. If you can ensure sufficient memory then it should cause any problems.. if you graph the timing of above command you should even be able to see when you need to add more memory. -- Jesper -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
