From: | Samuel Gendler <sgendler(at)ideasculptor(dot)com> |
---|---|
To: | "Reuven M(dot) Lerner" <reuven(at)lerner(dot)co(dot)il> |
Cc: | Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Very long deletion time on a 200 GB database |
Date: | 2012-02-24 08:22:21 |
Message-ID: | CAEV0TzB=zeYBO_T-kcKgcSA4DwRJ6Ka5MPfDhZ_hZ8pWc40QbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Feb 23, 2012 at 10:39 PM, Reuven M. Lerner <reuven(at)lerner(dot)co(dot)il>wrote:
> Hi, everyone.
>
> So it turns out that we're not using 25 GB of virtual memory. (That's
> what I had been shown yesterday, and it was a bit surprising, to say the
> least...)
>
> A few statistics that I managed to get from the Windows developers/system
> administrators:
>
> - The machine has a total of 3.5 GB of RAM
> - shared_buffers was set to 256 MB (yes, MB!)
> - Virtual memory usage by our process is 3 MB (yes, MB)
> - CPU is virtually idle when running the deletes, using about 1% of CPU
> - No other processes are accessing the database when we're running the
> maintenance; there are a total of three server processes, but two are idle.
>
What is work_mem set to? If all the other values were set so low, I'd
expect work_mem to also be small, which could be causing all kind of disk
activity when steps don't fit into a work_mem segment.
From | Date | Subject | |
---|---|---|---|
Next Message | Reuven M. Lerner | 2012-02-24 12:37:30 | Re: Very long deletion time on a 200 GB database |
Previous Message | Reuven M. Lerner | 2012-02-24 06:39:48 | Re: Very long deletion time on a 200 GB database |