Re: vacuumdb causes memory drain.

[Sushil Shirodkar <sushilps@xxxxxxxxxxx>]

---

From: Laurenz Albe <laurenz.albe@xxxxxxxxxxx>
Sent: Monday, April 30, 2018 1:43 AM
To: Sushil Shirodkar
Cc: don@xxxxxxxxx; pgsql-admin@xxxxxxxxxxxxxx
Subject: Re: vacuumdb causes memory drain.

 

Sushil Shirodkar wrote:
> > > > > > > On Thu, Apr 26, 2018 at 10:31 AM, Sushil Shirodkar <sushilps@xxxxxxxxxxx> wrote:
> > > > > > > Running "vacuumdb -a -z -v" from the cron on one of our test environment, and
> > > > > > > noticed that memory of the server goes down from 3.4GB free to 150MB.  Once
> > > > > > > the process is over, memory is not released, is it normal or something needs to be
> > > > > > > changed ? also other processes start running slow afterwards due to low memory. 
>
> Process which was running close to 99% memory was
>  "/usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf"
>
> free -h - was showing between 100-150 mb free.
>
> shared_buffers = 1GB
> maintenance_work_mem = 256MB

Can you share the "free -h" output?

What do you get for
ps -p <postmaster PID> -o rss,trs,drs,vsz,%mem
if you substitute the postmaster's process ID?

If you say that "sync" restored normal behavior, are you implying that there
was a high I/O load?

Still trying to figure out what exactly you are experiencing.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

Startseite - Cybertec www.cybertec-postgresql.com The PostgreSQL Company CYBERTEC – Ihr professioneller PostgreSQL-Partner für Support, Services, Updates und individuelle Schulungen. CYBERTEC PostgreSQL Services CYBERTEC PostgreSQL Trainings und Kurse CYBERTEC PostgreSQL Applikationen Durch unsere jahrelange Erfahrung mit PostgreSQL haben wir bereits eine Vielzahl an Applikationen ...

Hi Laurenz,

After reboot of Linux server this morning, we couldn't reproduce the issue.  Not sure if this will come up 

again, and if it is good news or not,  will monitor and update forum if it reoccurs.  

Pl. see the output below which I had captured earlier from  "free -h" before and after

running of  "vacuumdb".

              total                 used         free          shared     buff/cache   available

Mem:           3.7G        158M        3.2G         62M        385M             3.3G

Swap:          3.9G          0B             3.9G

                     total        used           free           shared      buff/cache   available

Mem:           3.7G        169M        138M        117M        3.4G              3.2G

Swap:           3.9G          0B            3.9G

Was running the following command when slowness was observed.  The only issue I would see is memory

getting close to full,  after running the following  our application performance would get back to normal.  

sync;  echo 1 > /proc/sys/vm/drop_caches

Let us know if we should run any other commands to capture the output,  if it reoccurs. 

Thanks to you and Don for your input and help on this issue. 

Rgs, 

Sushil Shirodkar...