Re: vacuumdb causes memory drain.
From: Laurenz Albe <laurenz.albe@cybertec.at>
Sent: Monday, April 30, 2018 1:43 AM
To: Sushil Shirodkar
Cc: don@seiler.us; pgsql-admin@postgresql.org
Subject: Re: vacuumdb causes memory drain.
Sent: Monday, April 30, 2018 1:43 AM
To: Sushil Shirodkar
Cc: don@seiler.us; pgsql-admin@postgresql.org
Subject: Re: vacuumdb causes memory drain.
Sushil Shirodkar wrote:
> > > > > > > On Thu, Apr 26, 2018 at 10:31 AM, Sushil Shirodkar <sushilps@hotmail.com> 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
Hi Laurenz,
> > > > > > > On Thu, Apr 26, 2018 at 10:31 AM, Sushil Shirodkar <sushilps@hotmail.com> 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
 | 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 ... | |
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...
В списке pgsql-admin по дате отправления: