Re: [PERFORM] Odd sudden performance degradation related to tempobject churn
От | Scott Marlowe |
---|---|
Тема | Re: [PERFORM] Odd sudden performance degradation related to tempobject churn |
Дата | |
Msg-id | CAOR=d=3+N1467oddeN3E7r2PKELQt+85s+c+JjP-tgRHoYukpA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] Odd sudden performance degradation related to temp object churn (Jerry Sievers <gsievers19@comcast.net>) |
Ответы |
Re: [PERFORM] Odd sudden performance degradation related to tempobject churn
|
Список | pgsql-performance |
On Mon, Aug 14, 2017 at 5:10 PM, Jerry Sievers <gsievers19@comcast.net> wrote: > Peter Geoghegan <pg@bowt.ie> writes: > >> On Mon, Aug 14, 2017 at 12:53 PM, Jeremy Finzel <finzelj@gmail.com> wrote: >> >>> This particular db is on 9.3.15. Recently we had a serious performance >>> degradation related to a batch job that creates 4-5 temp tables and 5 >>> indexes. It is a really badly written job but what really confuses us is >>> that this job has been running for years with no issue remotely approaching >>> this one. We are also using pgpool. >> >> Did you happen to notice that this occurred when you upgrading point >> release? If so, what version did you move from/to? > > The system was last started back in November. Running 9.3.15. > > Not aware of any host system libs or whatever change recently but will investigate. So do iostat or iotop show you if / where your disks are working hardest? Or is this CPU overhead that's killing performance?
В списке pgsql-performance по дате отправления: