| From: | Fabrízio de Royes Mello <fabrizio(at)timbira(dot)com(dot)br> |
|---|---|
| To: | Marcelo Kruger <marcelo(dot)kruger(at)neoway(dot)com(dot)br> |
| Cc: | Shreeyansh Dba <shreeyansh2014(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Subject: | Re: [ADMIN] High replication lag - Stream Replication |
| Date: | 2017-12-28 14:48:44 |
| Message-ID: | CAPfkCSCFx2AbxF=VizWt3uYv=vTE6Nhpd_-PMoQ4uijOYbw8=Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Hi,
Please don't top posting...
2017-12-10 19:59 GMT-02:00 Marcelo Kruger <marcelo(dot)kruger(at)neoway(dot)com(dot)br>:
> We were able to reduce the volume of generated WAL files. In some cases we
> use UNLOGGED tables to assist in WAL reduction. But I still find it strange
> the process of recovery in the standby database use little CPU. Today the
> process uses between 20 and 50% of a CPU, not using all the processing that
> the machine offers (20 CPUs, RAID 0 on SSD).
>
>
Yes that's correct because we have just a single wal-receiver process on
standby.
> Is there any configuration that allows Postgres to use more processing at
> the time of the application of WAL files in the StandBy database?
>
>
Unfortunately no as I mentioned before...
Did you already run a 'perf top' or 'strace' on recovery process to try
understand what happen?
Sorry but I didn't read the entire thread.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2017-12-28 18:18:54 | Re: [ADMIN] High replication lag - Stream Replication |
| Previous Message | Timo Myyrä | 2017-12-26 13:14:55 | Re: Oracle to postgres migration |