|
regarding journaling, there is the counter argument that you do not need to do the same job twice, in the sense that we already spend a considerable amount of time retaining the WAL in postgresql, no need to redo the same on FS level. "Crush"-intensive systems (for lack of a better word) might benefit from FS journaling, but the best option here is try and find the cause. FreeBSD systems are supposed to not crush, that's why ppl use them in the first place.
On Τετ 20 Μαρ 2013 10:11:58 Vick Khera wrote: On Wed, Mar 20, 2013 at 7:49 AM, Dan Thomas <godders@xxxxxxxxx> wrote: Not all of our servers are leaking space, it's only the more recently-installed systems. Here's a quick breakdown of versions:
How long does it take for you to accumulate this "leak"? My first instinct is that you have unlinked files still referenced by some application. That is really the only way you get these discrepancies. lsof *should* have showed them to you. Try fstat in case there's some bug in lsof. Also, your tunefs output seems to be not from FreeBSD 9.1. Specifically, it is not emitting this line: tunefs: soft update journaling: (-j) disabled It is a very useful option to turn on for large file systems. I can recover a 6TB file system in about 5 seconds on a crash reboot with that on. [root@d04]# ps axuw34214 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND pgsql 34214 0.0 0.5 5426964 154484 0- S 28Feb13 1:30.66 /usr/local/bin/postgres -D /u/data/postgres [root@d04]# df -h /u/data Filesystem Size Used Avail Capacity Mounted on /dev/ufs/ramdisk 707G 137G 513G 21% /u/data [root@d04]# du -sh /u/data 137G /u/data [root@d04]# uname -a FreeBSD d04.m1e.net 9.1-RELEASE FreeBSD 9.1-RELEASE #1 r243808: Mon Dec 3 09:56:27 EST 2012 vivek@xxxxxxxxxxxxxxxxx:/usr/obj/u/lorax1/usr9/src/sys/KCI64 amd64 [root@d04]# uptime 9:50AM up 74 days, 17:36, 1 user, load averages: 0.21, 0.18, 0.17 [root@d04]# psql --version psql (PostgreSQL) 9.2.3 [root@d04]# - Achilleas Mantzios IT DEV IT DEPT Dynacom Tankers Mgmt |
