Re: vacuumdb causes memory drain. - Mailing list pgsql-admin

From Tim Cross
Subject Re: vacuumdb causes memory drain.
Date
Msg-id CAC=50j99pbNZ7AVpNZrCUiC8GpPa1bjfOj4ADUihK7xWOOVpRQ@mail.gmail.com
Whole thread Raw
In response to Re: vacuumdb causes memory drain.  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: vacuumdb causes memory drain.  (Sushil Shirodkar <sushilps@hotmail.com>)
List pgsql-admin


On 1 May 2018 at 13:05, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
Sushil Shirodkar wrote:
> 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

That is totally normal.

You can observe that in the second output all the memory is shown as "buff/cache",
that is, it is used for the file system cache rather than remaining unused.
This memory is available, there is no shortage.

This is the normal state for a Linux system with buffered I/O activity.

> after running the following  our application performance would get back to normal.
>
> sync;  echo 1 > /proc/sys/vm/drop_caches

Now that is surprising.

Sure, after running this command  your memory will show up as "free" again,
but I'd expect performance to get worse because no more files are cached.

Next time you run into trouble, try the following commands:

vmstat 1
iostat -mNx 1

These should show you how your overall CPU, memory and I/O situation is.
Maybe you can find your performance bottleneck that way.

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


as another indicator that your not low on memory look at the 'swap' line. The kernel has not swapped anything out of main memory, so while the 'free' value might look low, there has been no demand for memory which exceeds what you have available. 

I too find the fact clearing out caches seems to improve performance - that seems counter to what I'd expect too.  What filesystem type is the server using for PG?

--
regards,

Tim

--
Tim Cross

pgsql-admin by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: vacuumdb causes memory drain.
Next
From: Sushil Shirodkar
Date:
Subject: Re: vacuumdb causes memory drain.