From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Naytro Naytro <naytro(at)googlemail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance issue after upgrading from 9.4 to 9.6 |
Date: | 2017-03-09 17:28:19 |
Message-ID: | CA+TgmoYW2W2kkywArVLjVMsDx-Lr02D=A1eCE7Uqyj-gi+FOXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 9, 2017 at 7:47 AM, Naytro Naytro <naytro(at)googlemail(dot)com> wrote:
> We are having some performance issues after we upgraded to newest
> version of PostgreSQL, before it everything was fast and smooth.
>
> Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we
> upgraded to 9.6.2 with no improvement.
>
> Some information about our setup: Freebsd, Solaris (SmartOS), simple
> master-slave using streaming replication.
>
> Problem:
> Very high system CPU when master is streaming replication data, CPU
> goes up to 77%. Only one process is generating this load, it's a
> postgresql startup process. When I attached a truss to this process I
> saw a lot o read calls with almost the same number of errors (EAGAIN).
> read(6,0x7fffffffa0c7,1) ERR#35 'Resource temporarily unavailable'
>
> Descriptor 6 is a pipe
>
> Read call try to read one byte over and over, I looked up to source
> code and I think this file is responsible for this behavior
> src/backend/storage/ipc/latch.c. There was no such file in 9.4.
Our latch implementation did get overhauled pretty thoroughly in 9.6;
see primarily commit 98a64d0bd713cb89e61bef6432befc4b7b5da59e. But I
can't guess what is going wrong here based on this information. It
might help if you can pull some stack backtraces from the startup
process.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-03-09 17:42:13 | Re: partial indexes and bitmap scans |
Previous Message | Mark Dilger | 2017-03-09 17:27:07 | Re: use SQL standard error code for nextval |