Since the commitlog/WAL is sequential-write, does it mattert that much to put it in ssd ?(i understand that it matters to put it in separate disk-subsystem so the write/read patterns don't interfere)
On Tue, May 6, 2014 at 1:07 PM, Michael Stone <mstone+postg...@mathom.us>wrote: > On Tue, May 06, 2014 at 11:13:42AM +0200, Johann Spies wrote: > >> Analysis or the SAR-logs showed that there were too much iowait in the >> CPU's on >> the old system which has a lower spec CPU than the ones considered for >> the new >> system. >> > > iowait means the cpu is doing nothing but waiting for data from the disk. > buying faster cpus means that they will be able to spend more time waiting > for data from the disk. you'd probably get much better bang for the buck > upgrading the storage subsystem than throwing more money at cpus. > > > We are looking possibly the following hardware: >> >> CPU: 2 x Ivy Bridge 8C E5-2667V2 3.3G 25M 8GT/s QPI - 16 cores >> RAM: 24 x 32GB DDR3-1866 2Rx4 LP ECC REG RoHS - 768Gb >> >> with enough disk space - about 4.8 Tb on RAID 10. >> My question is about the possible advantage and usage of SSD disks in the >> new >> server. >> > > At the moment I am considering using 2 x 200GB SSD' s for a separate >> partion for temporary files and 2 x 100GB for the operating system. >> > > If you're talking about SSDs for the OS, that's a complete waste; there is > essentially no I/O relating to the OS once you've booted. > > > So my questions: >> >> 1. Will the SSD's in this case be worth the cost? >> 2. What will the best way to utilize them in the system? >> > > The best way to utilize them would probably be to spend less on the CPU > and RAM and more on the storage, and use SSD either for all of the storage > or for specific items that have a high level of I/O (such as the indexes). > Can't be more specific than that without a lot more information about the > database, how it is utilized, and what's actually slow. > > Mike Stone > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >