On 11/22/10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jon Nelson <jnelson+pgsql@jamponi.net> writes:
>> Here is the problem: When I started benchmarking this application, I
>> noticed it (postgresql) started chewing up inodes on the logical
>> volume which houses /var/lib/pgsql. It chewed up a few thousand
>> inodes, and then a few thousand more, and then there were no more.
>
>> I investigated /var/lib/pgsql/data/ and found within the database's
>> directory many thousands of 0-byte files. I stopped the application
>> expecting at the end of a /session/ that the inodes would be unlinked,
>> but there was no change. lsof told me nobody had them open. However, a
>> start/stop of postgresql removed (at least most of) the 0-byte files.
>> After some trial and error, I straced the right process (the bgwriter
>> process) and found that, upon signal to leave, it would write some
>> checkpoint-y stuff and then proceed about unlinking most or all of the
>> 0-byte files.
>
> This is not a bug; it's normal behavior when dropping a table. The
> table file is truncated to zero bytes at commit, but it's not unlinked
> until the next checkpoint. I surmise that you may have a very long
> checkpoint cycle time selected.
Indeed I do. An explicit CHECKPOINT also clears the inodes up.
I was very surprised to chew threw some 16 thousand inodes in a minute or two.
Thanks!
--
Jon