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 <godd...@gmail.com> wrote:

Not all of our servers are leaking space, it's only the more recently-installed 
systems. Here's a quick breakdown of versions:


FWIW, I do not observe this behavior. My database has very heavy write load, 
and old data is purged after it is aged about 7 months, so I do get lots of 
fragmentation. However, I do not have any disk space "phantom" loss.


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     
vi...@lorax.kcilink.com:/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

Reply via email to