On Fri, Dec 17, 2010 at 5:22 PM, Gauthier, Dave <dave.gauthier@intel.com> wrote:
> max_fsm_pages = 200000
> max_fsm_relations = 12000
>
> There are 12 DBs with roughly 30 tables+indexes each.
>
> There are apparently 2 "bad" DBs. Both identical in terms of data models (clones with different data). I've
pg_dummpedone of them to a file, dropped the DB (took a long time as millions of files were deleted) and recreated it.
Itnow has 186 files.
>
> ls -1 | wc took a while for the other bad one but eventually came up with exactly 7,949,911 files, so yes, millions.
Theother one had millions too before I dropped it. Something is clearly wrong. But, since the DB recreate worked for
theother one, I'll do the same thing to fix this one too.
>
> What I will need to know then is how to prevent this in the future. It's very odd because the worst of the 2 bad DBs
wasa sister DB to one that's no problem at all. Here's the picture...
>
> I have a DB, call it "foo", that gets loaded with a ton of data at night. The users query the thing readonly all
day. At midnight, an empty DB called "foo_standby", which is identical to "foo" in terms of data model is reloaded from
scratch. It takes hours. But when it's done, I do a few rename databases to swap "foo" with "foo_standby" (really just
aname swap). "foo_standby" serves as a live backup of yesterday's data. Come the next midnight, I truncate all the
tablesand start the process all over again.
maybe something in this process is leaking files. if I was in your
shoes, I'd recreate the database from scratch, then watch the file
count carefully and look for unusual growth. this is probably not the
case, but if it is in fact a backend bug it will turn up again right
away.
anything else interesting jump out about these files? for example, are
there a lot of 0 byte files?
merlin
