Обсуждение: BUG #6365: Memory leak in insert and update
The following bug has been logged on the website: Bug reference: 6365 Logged by: Otto Havasv=C3=B6lgyi Email address: havasvolgyi.otto@gmail.com PostgreSQL version: 9.1.2 Operating system: Win XP SP2 x86; Linux Debian 2.6.32 kernel x64 Description:=20=20=20=20=20=20=20=20 The bug can be reproduced with pgbench: Insert script: \set nbranches 1*:scale \set ntellers 10*:scale \set naccounts 100000*:scale \setrandom aid 1 :naccounts \setrandom bid 1 :nbranches \setrandom tid 1 :ntellers \setrandom delta -5000 5000 insert into pgbench_history (tid, bid, aid, delta, mtime) values (:tid, :bid, :aid, :delta, current_timestamp); Update script: \set nbranches 1*:scale \set ntellers 10*:scale \set naccounts 100000*:scale \setrandom aid 1 :naccounts \setrandom bid 1 :nbranches \setrandom tid 1 :ntellers \setrandom delta -5000 5000 update pgbench_accounts set abalance =3D abalance + :delta where aid =3D :a= id; Steps: ./pgbench -i -Uotto test ./pgbench -c1 -j1 -T200 -Msimple -N -r -v -f insert.sql -Uotto testdb ./pgbench -c1 -j1 -T200 -Msimple -N -r -v -f update.sql -Uotto testdb During this test a continuous increase of the backend memory comsumption can be observed. During the insert test the increase is quite bigger than during update.
havasvolgyi.otto@gmail.com writes:
> The following bug has been logged on the website:
> Bug reference: 6365
> Logged by: Otto Havasvölgyi
> Email address: havasvolgyi.otto@gmail.com
> PostgreSQL version: 9.1.2
> Operating system: Win XP SP2 x86; Linux Debian 2.6.32 kernel x64
> Description:
> The bug can be reproduced with pgbench:
I see no memory leak with this example.
I suspect you are being fooled by tools that report shared memory as
being used by a process only after it first touches a given page of
shared memory ("top" on Linux does that, for example). This will cause
the apparent memory consumption of any long-lived backend to increase
until it has touched every available shared buffer. But that's not a
leak, just an artifact of the reporting tool. You can confirm for
yourself that that's what's happening by reducing shared_buffers to
a few megabytes and observing that reported memory usage increases up
to that much and then stops growing.
On Linux, I find that watching the "VIRT" column of top output is a
far more reliable guide to whether a memory leak is actually occuring.
Can't offer any suggestions as to what to use on Windows.
regards, tom lane
On Thu, Dec 29, 2011 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> havasvolgyi.otto@gmail.com writes:
>> The following bug has been logged on the website:
>> Bug reference: =A0 =A0 =A06365
>> Logged by: =A0 =A0 =A0 =A0 =A0Otto Havasv=F6lgyi
>> Email address: =A0 =A0 =A0havasvolgyi.otto@gmail.com
>> PostgreSQL version: 9.1.2
>> Operating system: =A0 Win XP SP2 x86; Linux Debian 2.6.32 kernel x64
>> Description:
>
>> The bug can be reproduced with pgbench:
>
> I see no memory leak with this example.
>
> I suspect you are being fooled by tools that report shared memory as
> being used by a process only after it first touches a given page of
> shared memory ("top" on Linux does that, for example). =A0This will cause
> the apparent memory consumption of any long-lived backend to increase
> until it has touched every available shared buffer. =A0But that's not a
> leak, just an artifact of the reporting tool. =A0You can confirm for
> yourself that that's what's happening by reducing shared_buffers to
> a few megabytes and observing that reported memory usage increases up
> to that much and then stops growing.
>
> On Linux, I find that watching the "VIRT" column of top output is a
> far more reliable guide to whether a memory leak is actually occuring.
> Can't offer any suggestions as to what to use on Windows.
This is by the way a FAQ:
http://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.=
3F
merlin
Merlin Moncure <mmoncure@gmail.com> writes: > On Thu, Dec 29, 2011 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I see no memory leak with this example. > This is by the way a FAQ: > http://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.3F Well, to be fair, the FAQ entry didn't mention this behavior of reported usage increasing over time. But it seems like a good place to document that, so I just added a paragraph about it. regards, tom lane
Thanks for the quick response. Linux's top fooled me quite a bit.<br />Excuse me for the false report.<br /><br />Best
regards,<br/>Otto<br /><br /><br /><div class="gmail_quote">2011/12/29 Tom Lane <span dir="ltr"><<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span><br/><blockquote class="gmail_quote" style="margin:0pt
0pt0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><a
href="mailto:havasvolgyi.otto@gmail.com">havasvolgyi.otto@gmail.com</a>writes:<br /> > The following bug has been
loggedon the website:<br /> > Bug reference: 6365<br /> > Logged by: Otto Havasvölgyi<br /> >
Emailaddress: <a href="mailto:havasvolgyi.otto@gmail.com">havasvolgyi.otto@gmail.com</a><br /> > PostgreSQL
version:9.1.2<br /> > Operating system: Win XP SP2 x86; Linux Debian 2.6.32 kernel x64<br /> > Description:<br
/><br/> > The bug can be reproduced with pgbench:<br /><br /></div>I see no memory leak with this example.<br /><br
/>I suspect you are being fooled by tools that report shared memory as<br /> being used by a process only after it
firsttouches a given page of<br /> shared memory ("top" on Linux does that, for example). This will cause<br /> the
apparentmemory consumption of any long-lived backend to increase<br /> until it has touched every available shared
buffer. But that's not a<br /> leak, just an artifact of the reporting tool. You can confirm for<br /> yourself that
that'swhat's happening by reducing shared_buffers to<br /> a few megabytes and observing that reported memory usage
increasesup<br /> to that much and then stops growing.<br /><br /> On Linux, I find that watching the "VIRT" column of
topoutput is a<br /> far more reliable guide to whether a memory leak is actually occuring.<br /> Can't offer any
suggestionsas to what to use on Windows.<br /><br /> regards, tom lane<br
/></blockquote></div><br/>