High WriteLatency RDS Postgres 9.3.20

From: Juan Manuel Cuello <juanmacuello(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: High WriteLatency RDS Postgres 9.3.20
Date: 2018-06-18 21:43:06
Message-ID: CALXCfb1B14Rqz5yxb5N5KcxzJyvnP5sQ+Xrubua_zWq3+mgW1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

I'm experiencing high WriteLatency levels in a Postgres server 9.3.20
hosted in Amazon RDS. So far it's been almost two months of investigation
and people at AWS technical support don't seem to find the cause. I think
it could be related to Postgres and the number of schema/tables in the
database, that's why I post this issue here.

I have around 4600 schemas, each contains 62 tables. The DB size is only
around 130 GB. the server has plenty of available RAM, CPU usage is less
than 10% and there are only around 16 connections, but WriteLatency is
unusually high.

As I don't have access to the server, I cannot see which are the process
that are wiring to disk, but my guess is that each Postgres process is
writing to disk for some reason.

This issue doesn't seem related to workload. If I restart the server,
WriteLatency drops to normal levels and remains like that until, after some
time (a few hours or a day), without any obvious reason, it spikes again
and continues at high levels since then.

Is it possible that, for some reason, Postgres processes start writing to
disk at some point due to reaching any internal limit? Maybe related to
relcache/catcache/syscache? Any other thoughts?

Thanks

Juan

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2018-06-18 22:04:20 Re: Query hitting empty tables taking 48 minutes
Previous Message Peter Geoghegan 2018-06-18 21:17:10 Re: What to do when dynamic shared memory control segment is corrupt