Thread: memory leak while using vaccum

memory leak while using vaccum

From
Achim Krümmel
Date:
I am running a PostgreSQL 7.1.3 on a Intel Pentium III
My operating system is SuSE Linux 7.1 with Kernel 2.4.4 (ELF)
I compiled postgresql with gcc 2.95.2
My problem:
when using "vacuum analyze <tablename>" on very large tables (I have one
with about 30GB) the memory usage increases continues until no memory is
left and the kernel stops this process.

I suppose this problem is easy to reproduce. Just create a table like
this:
          Table "wa_cube"Attribute |     Type      | Modifier
-----------+---------------+----------dim1      | numeric(38,0) |dim2      | numeric(38,0) |dim3      | numeric(38,0)
|dim4     | numeric(38,0) |dim5      | numeric(38,0) |lvkumsatz | numeric(14,3) |vkumsatz  | numeric(14,3) |ekumsatz  |
numeric(14,3)|menge     | numeric(14,3) | 
Index: wa_cube_idx

fill very much data into it, then create an index like this:
   Index "wa_cube_idx"Attribute |     Type
-----------+---------------dim1      | numeric(38,0)dim2      | numeric(38,0)dim3      | numeric(38,0)dim4      |
numeric(38,0)
btree

and run: vacuum anayze <table>


greetings,  Achim Kruemmel


Re: memory leak while using vaccum

From
Tom Lane
Date:
Achim Krümmel <akruemmel@dohle.com> writes:
> when using "vacuum analyze <tablename>" on very large tables (I have one
> with about 30GB) the memory usage increases continues until no memory is
> left and the kernel stops this process.

I don't have 30Gb to spare, but I set up a table of the same schema with
a couple hundred meg of toy data and vacuumed it.  I didn't see any
significant memory usage (about 8 meg max).

If there is a lot of free space in your 30Gb table then it's possible
that the problem is simply vacuum's data structures that keep track
of free space.  What exactly are you using as the process memory limit,
and can you increase it?

FWIW, the default vacuum method for 7.2 is designed to use a fixed
amount of memory no matter how large the table.  That won't help you
much today, however.
        regards, tom lane