Re: leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume
От | Magnus Hagander |
---|---|
Тема | Re: leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume |
Дата | |
Msg-id | CABUevExY-SoqEzvvwuXUJY4o3_t2=H912Z-q3=hKCriYQZ7Pxg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: leaking lots of unreferenced inodes (pg_xlog files?), maybe after moving tables and indexes to tablespace on different volume (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: leaking lots of unreferenced inodes (pg_xlog files?),
maybe after moving tables and indexes to tablespace on different volume
|
Список | pgsql-hackers |
<p dir="ltr"><br /> On Mar 13, 2013 3:04 AM, "Tom Lane" <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > Palle Girgensohn <girgen@FreeBSD.org>writes:<br /> > > ... I got lots of space freed<br /> > > up, but it seems that afterthat the disk usage grows linearly (it seems<br /> > > to leave many inodes unreferenced).<br /> ><br /> >Hm. We've seen issues in the past with PG processes failing to close<br /> > no-longer-useful files promptly, but...<br /> ><br /> > > Strange thing is I cannot find any open files.<br /> ><br /> > ... that suggeststhere's something else going on.<br /> ><br /> > > The unreferenced inodes are almost exclusively around16 MB in size, so<br /> > > i.e. they would most probably all be pg_xlog files.<br /> ><br /> > Have yougot any sort of WAL archiving active, and if so maybe that's<br /> > holding onto WAL files? Not that it's clear howcome lsof wouldn't<br /> > tattle on an archiving process either.<br /> ><br /> > > Stopping postgresql brieflydid not help, I tried that.<br /> ><br /> > That seems to point the finger at some non-postgres cause. I confess<br/> > I can't guess what.<br /> ><p dir="ltr">Yeah, unreferenced inodes with no open files, and only discoverablewith fsck sounds like a filsystem bug to me. Particularly since it showed up just after a operating system upgrade,and doesn't go away with a postgres restart... <p dir="ltr">/Magnus
В списке pgsql-hackers по дате отправления: