From: | "Graeme B(dot) Bell" <grb(at)skogoglandskap(dot)no> |
---|---|
To: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres is using 100% CPU |
Date: | 2015-06-02 07:47:29 |
Message-ID: | 7EF5206B-3427-4349-A0A1-974862D61017@skogoglandskap.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sun, May 31, 2015 at 7:53 PM, Yves Dorfsman <yves(at)zioup(dot)com> wrote:
>> That's the thing, even on an old laptop with a slow IDE disk, 273
> individual
>> inserts should not take more than a second.
>
I think that would depend on settings such as synchronous_commit, commit_delay, or whether 2-phase commit is being used.
If synchronous commit is enabled and commit_delay was not used (e.g. 0), and you have a client synchronously making individual inserts to the DB (1 transaction each), then surely you have delays due to waiting for each transaction to commit synchronously to WAL on disk?
I believe yes / 0 are the default settings for synchronous commit and commit_delay. (Interestingly the manual pages do not specify.)
Assuming a 5400RPM laptop drive (which is a typical drive - some laptop drives run < 5000RPM), and assuming you are writing a sequential log to disk (with very short gaps between entries being added, e.g. no seek time, only rotational latency) will mean 5400 transactions per minute, 1 write per rotation.
That's a maximum 90 transactions per second synchronised to WAL. It would take just over 3 seconds.
Ashik, try altering your postgresql.conf to say 'commit_delay=100' or 'synchronous_commit=off'. Let us know if that fixes the problem. Read up on the options before you change them.
Graeme Bell
From | Date | Subject | |
---|---|---|---|
Next Message | Graeme B. Bell | 2015-06-02 07:58:54 | Re: Postgres is using 100% CPU |
Previous Message | Tomas Vondra | 2015-06-01 21:21:10 | Re: Connection time when using SSL |