On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund <and...@anarazel.de> wrote:
> >> The bottom line >> here, IMHO, is not that there's anything wrong with our ring buffer >> implementation, but that if you run PostgreSQL on a system where the >> I/O is hitting a 5.25" floppy (not to say 8") the performance may be >> less than ideal. I really appreciate IBM donating hydra - it's been >> invaluable over the years for improving PostgreSQL performance - but I >> sure wish they had donated a better I/O subsystem. When I had this problem some years ago, I traced it down to the fact you have to sync the WAL before you can evict a dirty page. If your vacuum is doing a meaningful amount of cleaning, you encounter a dirty page with a not-already-synced LSN about once per trip around the ring buffer. That really destroys your vacuuming performance with a 256kB ring if your fsync actually has to reach spinning disk. What I ended up doing is hacking it so that it used a BAS_BULKWRITE when the vacuum was being run with a zero vacuum cost delay. > It's really not just hydra. I've seen the same problem on 24 disk raid-0 > type installations. The small ringbuffer leads to reads/writes being > constantly interspersed, apparently defeating readahead. Was their a BBU on that? I would think slow fsyncs are more likely than defeated readahead. On the other hand, I don't hear about too many 24-disk RAIDS without a BBU. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
