> Very much agree with this. Because SSD is fast doesn't make it suited for > certain things, and a streaming sequential 100% write workload is one of > them. I've worked with everything from local disk to high-end SAN and even > at the high end we've always put any DB logs on spinning disk. RAID1 is > generally sufficient. SSD is king for read heavy random I/O workload.
1. Here we found SSD sustained serial writes were faster on SSD than to disk, by a factor of 3, both in RAID and single disk configurations. 2. Also, something to watch out for is extended stalls due to synchronous write activity / clearing out of cache, when a lot of data has been building up in write caches. By placing the WAL on the same disk as the ordinary database, you avoid having too much dirty cache building up because the WAL forces the disk to flush more often. So you can trade off some DB filesystem performance here to avoid blocking / IO lag spikes. 3. There's also the question of disk bays. When you have extra disks for OS, for logs, etc. , in some situations you're using up disks that could be used to extend your main database filesystem, particularly when those disks also need to be protected by the appropriate RAID mirrors and RAID hotspares. It can be cheaper to put the logs to SSD than to have 1 extra hdd + its RAID1 mirror + its hotspare + possible shelfspare, plus pay for a bigger chassis to have 3 more disk bays. 4. Finally there's the issue of simplicity. If you get a fast SSD and run OS/logs/DB off a single RAID volume, there's less chance for error when some unlucky person has to do an emergency fix/rebuild later, than if they have to check disk caching policy etc across a range of devices and ensure different parts of the filesystem are mounted in all the right places. Makes documentation easier. Graeme Bell -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
