Thread: PostgreSQL Full Vacuum Taking 5 to 6 hrs.
Hi Team,
We are using Postgres -11 version and when we running Full vacuum it will take 5 to 6 Hrs to complete full vacuum.
Please suggest how to reduce the full vacuum time.
OS Version : RHEL6
DB size -450 GB
Postgresql Version -11
Regards,
Ram Pratap.
Hi, On Tue, Feb 08, 2022 at 06:25:01AM +0000, Ram Pratap Maurya wrote: > > We are using Postgres -11 version and when we running Full vacuum it will > take 5 to 6 Hrs to complete full vacuum. What do you mean by "full vacuum" exactly? Is it a plain VACUUM FULL? If yes, on all tables or only some specific ones?
Hi Julien, we are running VACUUM FULL on all table and its take 5 to 6 Hrs. Regards, Ram Pratap. -----Original Message----- From: Julien Rouhaud [mailto:rjuju123@gmail.com] Sent: 08 February 2022 12:23 To: Ram Pratap Maurya Cc: 'pgsql-admin@lists.postgresql.org'; Ashish Chugh Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs. Hi, On Tue, Feb 08, 2022 at 06:25:01AM +0000, Ram Pratap Maurya wrote: > > We are using Postgres -11 version and when we running Full vacuum it > will take 5 to 6 Hrs to complete full vacuum. What do you mean by "full vacuum" exactly? Is it a plain VACUUM FULL? If yes, on all tables or only some specific ones?
Hi, Please don't top post on those forums (https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics) On Tue, Feb 08, 2022 at 06:59:07AM +0000, Ram Pratap Maurya wrote: > > we are running VACUUM FULL on all table and its take 5 to 6 Hrs. The only thing that can be done to make it faster is to use a 1GB maintenance_work_mem. But why do you need to do frequent database wide VACUUM FULL in the first place? Do you really have massive bloat on every single table in the database? Do you have adequate autovacuum configuration, or additional VACUUM jobs if that's not enough?
HI Julien, In my current database index size is very large compare than table (if table size is 30 GB and index size is 90GB) , thatwhy We running full vacuum monthly basis to increase the system performance and data reclaim . Auto Vacuum is also configuration in system. As per your suggesion if we increase " maintenance_work_mem " paramater size to 1GB this will be help to improve full vacuumperformance?. System configuration as below: CPU - 42 RAM -70GB Regards, Ram Pratap. -----Original Message----- From: Julien Rouhaud [mailto:rjuju123@gmail.com] Sent: 08 February 2022 12:38 To: Ram Pratap Maurya Cc: 'pgsql-admin@lists.postgresql.org'; Ashish Chugh Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs. Hi, Please don't top post on those forums (https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics) On Tue, Feb 08, 2022 at 06:59:07AM +0000, Ram Pratap Maurya wrote: > > we are running VACUUM FULL on all table and its take 5 to 6 Hrs. The only thing that can be done to make it faster is to use a 1GB maintenance_work_mem. But why do you need to do frequent database wide VACUUM FULL in the first place? Do you really have massive bloat on everysingle table in the database? Do you have adequate autovacuum configuration, or additional VACUUM jobs if that's not enough?
HI Julien, In my current database index size is very large compare than table (if table size is 30 GB and index size is 90GB) , thatwhy We running full vacuum monthly basis to increase the system performance and data reclaim . Auto Vacuum is also configuration in system. " maintenance_work_mem " paramater size to 2GB configure in system. System configuration as below: CPU - 42 RAM -70GB Regards, Ram Pratap. -----Original Message----- From: Julien Rouhaud [mailto:rjuju123@gmail.com] Sent: 08 February 2022 12:38 To: Ram Pratap Maurya Cc: 'pgsql-admin@lists.postgresql.org'; Ashish Chugh Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs. Hi, Please don't top post on those forums (https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics) On Tue, Feb 08, 2022 at 06:59:07AM +0000, Ram Pratap Maurya wrote: > > we are running VACUUM FULL on all table and its take 5 to 6 Hrs. The only thing that can be done to make it faster is to use a 1GB maintenance_work_mem. But why do you need to do frequent database wide VACUUM FULL in the first place? Do you really have massive bloat on everysingle table in the database? Do you have adequate autovacuum configuration, or additional VACUUM jobs if that's not enough?
Hi Team,
We are using Postgres -11 version and current PG DB size is 450 GB .
Archive log enable in Database and we are running Full PG_Base backup and it will take 8 to 8:30 Hrs to complete the backup ,
Please suggest how to reduce the full DB backup time.
OS Version : RHEL6
DB size -450 GB
Postgresql Version -11
Regards,
Ram Pratap.
Maybe your storage subsystem is really slow.
Maybe you're only running one thread.
Maybe it's being blocked by other users.
We don't know because you've barely told us anything.
Not to mention: VACUUM FULL is only useful after you've updated or deleted a major portion of a table all at once.
HI Julien, In my current database index size is very large compare than table (if table size is 30 GB and index size is 90GB) , that why We running full vacuum monthly basis to increase the system performance and data reclaim . Auto Vacuum is also configuration in system. As per your suggesion if we increase " maintenance_work_mem " paramater size to 1GB this will be help to improve full vacuum performance?. System configuration as below: CPU - 42 RAM -70GB Regards, Ram Pratap. -----Original Message----- From: Julien Rouhaud [mailto:rjuju123@gmail.com] Sent: 08 February 2022 12:38 To: Ram Pratap Maurya Cc: 'pgsql-admin@lists.postgresql.org'; Ashish Chugh Subject: Re: PostgreSQL Full Vacuum Taking 5 to 6 hrs. Hi, Please don't top post on those forums (https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics) On Tue, Feb 08, 2022 at 06:59:07AM +0000, Ram Pratap Maurya wrote:we are running VACUUM FULL on all table and its take 5 to 6 Hrs.The only thing that can be done to make it faster is to use a 1GB maintenance_work_mem. But why do you need to do frequent database wide VACUUM FULL in the first place? Do you really have massive bloat on every single table in the database? Do you have adequate autovacuum configuration, or additional VACUUM jobs if that's not enough?
Angular momentum makes the world go 'round.
PG15 DB Error :::could not receive data from client: Connection reset by peer
Dear Team,
We are getting error frequently in PostgresDB:15 log file , Please suggest why this error is coming and what is workaround to solve this error.
/var/lib/pgsql/15/data/log/postgresql-Tue.log:2025-02-18 08:07:32.309 IST [1166457] LOG: could not receive data from client: Connection reset by peer
/var/lib/pgsql/15/data/log/postgresql-Tue.log:2025-02-18 08:07:32.310 IST [1166411] LOG: could not receive data from client: Connection reset by peer
Regards,
Ram Pratap.
Re: PG15 DB Error :::could not receive data from client: Connection reset by peer
On Wed, 2025-02-19 at 06:16 +0000, Ram Pratap Maurya wrote: > We are getting error frequently in PostgresDB:15 log file , > Please suggest why this error is coming and what is workaround to solve this error. > > /var/lib/pgsql/15/data/log/postgresql-Tue.log:2025-02-18 08:07:32.309 IST [1166457] LOG: could not receive data from client:Connection reset by peer > /var/lib/pgsql/15/data/log/postgresql-Tue.log:2025-02-18 08:07:32.310 IST [1166411] LOG: could not receive data from client:Connection reset by peer That is a complaint by the server about the client connection being forcibly interrupted. Perhaps the client is not closing the database session correctly, perhaps some network component is misconfigured. I would first investigate what went on at the client side. Did the client get an error too? Yours, Laurenz Albe -- *E-Mail Disclaimer* Der Inhalt dieser E-Mail ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. *CONFIDENTIALITY NOTICE & DISCLAIMER *This message and any attachment are confidential and may be privileged or otherwise protected from disclosure and solely for the use of the person(s) or entity to whom it is intended. If you have received this message in error and are not the intended recipient, please notify the sender immediately and delete this message and any attachment from your system. If you are not the intended recipient, be advised that any use of this message is prohibited and may be unlawful, and you must not copy this message or attachment or disclose the contents to any other person.