X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 6161EDAFFF for ; Tue, 22 Nov 2005 11:26:16 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 62230-09 for ; Tue, 22 Nov 2005 15:26:19 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from soufre.accelance.net (soufre.accelance.net [213.162.48.15]) by svr1.postgresql.org (Postfix) with ESMTP id 8C28ADAFE3 for ; Tue, 22 Nov 2005 11:26:13 -0400 (AST) Received: from [213.162.49.207] (gs.team.openwide.fr [213.162.49.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by soufre.accelance.net (Postfix) with ESMTP id 63E965D2E; Tue, 22 Nov 2005 16:26:18 +0100 (CET) Message-ID: <43833899.5080408@openwide.fr> Date: Tue, 22 Nov 2005 16:26:17 +0100 From: Guillaume Smet User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ron CC: pgsql-performance@postgresql.org Subject: Re: weird performances problem References: <437CC21D.8070402@openwide.fr> <4382EB58.3020804@openwide.fr> <6.2.5.6.0.20051122074454.040fae60@earthlink.net> <43832AA3.6080606@openwide.fr> <6.2.5.6.0.20051122093227.040fd900@earthlink.net> In-Reply-To: <6.2.5.6.0.20051122093227.040fd900@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200511/443 X-Sequence-Number: 15700 Ron, First of all, thanks for your time. > As has been noted many times around here, put the WAL on its own > dedicated HD's. You don't want any head movement on those HD's. Yep, I know that. That's just we supposed it was not so important if it was nearly a readonly database which is wrong according to you. > _Something_ is doing long bursts of write IO on sdb and sdb1 every 30 > minutes or so according to your previous posts. It's not every 30 minutes. It's a 20-30 minutes slow down 3-4 times a day when we have a high load. Anyway apart from this problem which is temporary, we have cpu idle all the day when we don't have any io wait (and nearly no write) and the server is enough loaded to use all the 4 cpus. I don't think it's normal. It's not a very good idea but do you think we can put fsync to off during a few minutes to check if the WAL is effectively our problem? A simple reload of the configuration seems to take it into account. So can we disable it temporarily even when the database is running? If it is the case, I think we'll test it and if it solved our problem, we'll ask our customer to buy two new disks to have a specific RAID 1 array for the pg_xlog. > That's actually a reasonably high CS rate. Again, why? I'm not so surprised considering what I read before about Xeon multiprocessors, pg 7.4 and the famous context switch storm. We are planning a migration to 8.1 to (hopefully) solve this problem. Perhaps our problem is due to that high CS rate. -- Guillaume