On 03/20/2013 01:25 PM, Kevin Grittner wrote:
I saw something once which *might* be related. I don't recall the
OS of FS involved, but in an attempt to reduce the fragmentation of
files which started small and eventually grew large, a large
allocation of contiguous space was made on file creati
Dan Thomas wrote:
> We're seeing a problem with some of our FreeBSD/PostgreSQL
> servers "leaking" quite significant amounts of disk space:
> Stopping Postgres doesn't fix it, but rebooting does which points
> at the OS rather than PG to me. However, the leak is only
> apparent in the dedicated
> Any difference in the architecture of the two systems? (x86, amd64, etc..)
> Any difference in the respective output of
> % pg_config
Alas, no. Both identical machines running identical versions of
FreeBSD and PG. pg_config on the two machines matches exactly.
On 20 March 2013 15:37, Achilleas
On Ôåô 20 Ìáñ 2013 15:15:23 Dan Thomas wrote:
>
> We actually have another FreeBSD8.3/PG9.1 machine under different (but
> similar) load that *doesn't* demonstrate this behaviour. There's
> nothing obvious in the differences in usage patterns that we can see
> (we're not using any exotic features
> How long does it take for you to accumulate this "leak"?
It grows at between 2 and 4 gigabytes per day on average. It seems to
be related to load on the database, as it grows slower over the
weekends when the servers are under less load. Here's a graph that
shows growth of one server (from reboo
Of course, but does it make sense for you to pay the ~ 5%/day performance
penalty for the ~0.5%/year chance of having your system crush?
Unless your FreeBSD server is stuffed with exotic gamer hardware, i don't see
the likehood of crush getting larger than that.
On Τετ 20 Μαρ 2013 10:39:58 Vick
On Wed, Mar 20, 2013 at 10:34 AM, Achilleas Mantzios <
ach...@matrix.gatewaynet.com> wrote:
> 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,
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 be
On Wed, Mar 20, 2013 at 7:49 AM, Dan Thomas 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
On Τετ 20 Μαρ 2013 12:47:39 Dan Thomas wrote:
> > Did you do a detailed du during the supposed problem and after the reboot
> > and make a diff of those to fimd any invlolved files/dirs?
>
> du doesn't show the space in question (du -s shows the actual usage on
> disk, df is showing a much higher
> Did you do a detailed du during the supposed problem and after the reboot and
> make a diff of those to fimd any invlolved files/dirs?
du doesn't show the space in question (du -s shows the actual usage on
disk, df is showing a much higher number), so I doubt this will show
anything up. However
Did you do a detailed du during the supposed problem and after the reboot and
make a diff of those
to fimd any invlolved files/dirs?
That said, i think you might consider posting on freebsd-[questions|stable] as
well.
On Τετ 20 Μαρ 2013 11:49:07 Dan Thomas wrote:
Hi Guys,
We're seeing a proble
Hi Guys,
We're seeing a problem with some of our FreeBSD/PostgreSQL servers
"leaking" quite significant amounts of disk space:
> df -h /usr/local/pgsql/
Filesystem SizeUsed Avail Capacity Mounted on
/dev/mfid1s1d1.1T772G222G78%/usr/local/pgsql
> d
13 matches
Mail list logo
