Re: Postgres filling up hard drive with swap files

Joe Lester <joe_lester(at)sweetwater(dot)com> writes:
>> Simple fact of the matter is that you have apparently found a memory
>> leak. How Mac OS X deals with swapping is (more or less) unimportant.

> Wow, I sure hope not. I was really hoping to take care of the problem.

I think what you've found is an OS X bug.

I was able to replicate this behavior on OS X 10.3.5. All I did was
start the postmaster and then start a continuous loop in a shell window:
while true
do
psql -c "select count(*) from tenk1" regression
done
(tenk1 is just a test table with 10000 or so rows ... not very big.)
After a few thousand iterations I have more swapfiles than I did before.
The postmaster itself is certainly not leaking memory, and there are no
backends lasting longer than a fraction of a second, but the machine is
acting like it's got a problem. Watching top, I see the "free PhysMem"
steadily decrease to zero and then bounce back up to about 645M (out of
768M installed). Each time it bounces up, the VM pageouts count takes a
jump (otherwise pageouts doesn't move), and there's also a burst of disk
activity according to iostat. The cycle repeats every 45 seconds or so.
Meanwhile, the entire system has become exceedingly sluggish (opening
Safari is painful, for example, and even just switching front
application is visibly slow).

What I think is happening is that the system thinks that the memory
associated with the exited backends is still in use, and hence
faithfully hangs onto it and eventually swaps it out. Almost certainly,
this bug is specifically triggered by our use of SysV shared memory.
If Apple had this bug for every process spawned by OS X, they'd have
noticed and fixed it long since ;-). But SysV shmem is not a popular
feature on OS X (as evidenced by the ridiculously low default limits
on it) and it's easy to imagine such a bug going unnoticed if it's
only triggered by shmem usage.

A crude estimate of the leakage rate I'm seeing is about 2.5MB per
exited backend, which is in the same general area as the size of the
shared memory segment, so it seems plausible that the system is somehow
treating an "afterimage" of the shmem segment as live data that it needs
to swap out.

BTW, I tried hacking the backend to forcibly shmdt() just before exit,
just to see if that would work around the problem. No go; doesn't seem
to change the behavior at all. I can't think of anything else we could
do at the application level to dodge the problem.

Time to file a bug report. With Apple, not with us.

regards, tom lane