Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 004112E0038 for ; Tue, 8 Apr 2008 06:03:12 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 14366-01 for ; Tue, 8 Apr 2008 06:03:07 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by developer.postgresql.org (Postfix) with ESMTP id C0EDC2E0035 for ; Tue, 8 Apr 2008 06:03:01 -0300 (ADT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jj9jD-0001jw-Cq for pgsql-performance@postgresql.org; Tue, 08 Apr 2008 09:02:55 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Apr 2008 09:02:55 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Apr 2008 09:02:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: Looking for bottleneck during load test Date: Tue, 08 Apr 2008 11:02:44 +0200 Lines: 29 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200804/85 X-Sequence-Number: 29578 Hell, Robert wrote: > > I tried different other tools for random IO (including a self written one which does random lseek and read). > > > > This tool, started during one of our tests, achieves 2 iops (8k each). > > Started alone I get something about 1,500 iops with an avg latency of 100 ms. 1500 iops looks about right for 4x2 RAID 10 volume. What's your worst latency (as reported by the tool)? iowait is mostly seek time. > > We are using SAN (EMC CLARiiON CX 300) - are those ~7 MB/s really our bottleneck? Depending on your access pattern to the database, it could be (if you have lots of random IO, and 180 concurrent database threads can make any IO random enough). Are your queries read-mostly or a mix? > > Any other tuning ideas? Only generic ones: - Are your queries optimized, use indexes, etc.? - Try PostgreSQL 8.3 - if you have sequential seeks it can in theory make better use of data between connections. - Do you have enough memory dedicated to data caches, both in PostgreSQL and in the OS? (i.e. what is your shared_buffers setting?) - If the SAN can configure parameters such as prefetch (pre-read) and stripe size, try lowering them (should help if you have random IO).