Re: inferior SCSI performance
От | Christopher Browne |
---|---|
Тема | Re: inferior SCSI performance |
Дата | |
Msg-id | 60brt1szby.fsf@dev6.int.libertyrms.info обсуждение исходный текст |
Ответ на | Re: inferior SCSI performance (Andrew Sullivan <andrew@libertyrms.info>) |
Ответы |
Re: inferior SCSI performance
(Hannu Krosing <hannu@tm.ee>)
|
Список | pgsql-performance |
andrew@libertyrms.info (Andrew Sullivan) writes: > On Wed, Oct 01, 2003 at 07:14:32AM -0600, scott.marlowe wrote: >> FYI, on a Dual PIV2800 with 2 gig ram and a single UDMA 80 gig hard drive, >> I from 420 tps to 22 tps when I disable write caching. WOW. A factor of >> about 20 times slower. (pgbench -c 4 -t 100) > > That's completely consistent with tests Chris Browne has done here on > cache-enabled and cache-disabled boxes that we have. > > It's a _really_ big difference. The combination of battery-backed > write cache on your controller plus a real good UPS is quite possibly > the number one thing you can do to improve performance. For what > it's worth, I can't see how this is something special about Postgres: > even raw-filesystem type systems have to make sure the disk actually > has the data, and a write cache is bound to be a big help for that. Indeed. When I ran the tests, I found that JFS was preferable to XFS and ext3 on Linux on the machine with the big battery backed cache. (And the side-effect that it was getting yes, probably about 20x the performance of systems without the cache.) The FS-related result appeared surprising, as the "stories" I had heard suggested that JFS hadn't been particularly heavily tuned on Linux, whereas XFS was supposed to be the "speed demon." It is entirely possible that the result I saw was one that would reverse partially or even totally on a system LACKING that cache. XFS might "play better" when we're cacheless; the (perhaps only fabled) demerits of JFS being more than totally hidden if we add the cache. What I find disappointing is that it isn't possible to get SSD cards that are relatively inexpensive. A similarly fabulous performance increase _ought_ to be attainable if you could stick pg_xlog and pg_clog on a 256MB (or bigger!) battery-backed SSD, ideally one that plugs into a PCI slot. This should have the further benefit of diminishing the amount of mechanical activity going on, as WAL activity would no longer involve ANY i/o operations. Unfortunately, while there are companies hawking SSDs, they are in the "you'll have to talk to our salescritter for pricing" category, which means that they must be ferociously expensive. :-(. -- output = ("cbbrowne" "@" "libertyrms.info") <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land)
В списке pgsql-performance по дате отправления: