This refers to the performance problem reported in http://archives.postgresql.org/pgsql-performance/2008-04/msg00052.php
After some time of trial and error we found that changing the I/O scheduling algorithm to "deadline" improved I/O performance by a factor 4 (!) for this specific load test. It seems that the bottleneck in this case was actually in the Linux kernel. Since performance statements are useless without a description of the system and the type of load, I'll send a few details to make this report more useful for the archives: The machine is a PC with 8 AMD Opteron 885 CPUs and 32 GB RAM, attached to a HP EVA 8100 storage system with 72 disks. We are running 64-bit Linux 2.6.18-53.1.6.el5 from RedHat Enterprise 5.1. The I/O queue depth is set to 64. Our benchmark tools show a possible I/O performance of about 11000 transactions per second for random scattered reads of 8k blocks. PostgreSQL version is 8.2.4. The database system is a cluster with 6 databases containing tables up to a couple of GB in size. The whole database cluster takes about 200 GB of storage. The database load is a set of read-only statements, several of which have miserable execution plans and perform table and index scans. With the default I/O scheduler we observe a performance of about 600 I/O transactions or 7 MB per second. After booting with elevator=deadline both values increase by a factor of up to 4 and the query response times sink drastically. Yours, Laurenz Albe -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
