> 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
endwe've always put any DB logs on spinning disk. RAID1 is generally sufficient. SSD is king for read heavy random
I/Oworkload.
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
diskconfigurations.
2. Also, something to watch out for is extended stalls due to synchronous write activity / clearing out of cache, when
alot of data has been building up in write caches. By placing the WAL on the same disk as the ordinary database, you
avoidhaving too much dirty cache building up because the WAL forces the disk to flush more often. So you can trade off
someDB 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
usingup disks that could be used to extend your main database filesystem, particularly when those disks also need to be
protectedby the appropriate RAID mirrors and RAID hotspares. It can be cheaper to put the logs to SSD than to have 1
extrahdd + 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
lesschance for error when some unlucky person has to do an emergency fix/rebuild later, than if they have to check disk
cachingpolicy 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