Re: plpgsql function seems to be leaking memory
От | Guillaume Lelarge |
---|---|
Тема | Re: plpgsql function seems to be leaking memory |
Дата | |
Msg-id | 4863BA63.80501@lelarge.info обсуждение исходный текст |
Ответ на | Re: plpgsql function seems to be leaking memory (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
Tom Lane a écrit : > Guillaume Lelarge <guillaume@lelarge.info> writes: >> Tom Lane a écrit : >>> What do you have shared_buffers set to? I think you might be getting >>> fooled by top's treatment of shared memory (ie, it starts to count >>> shared pages after the process touches them for the first time). > >> That's what I thought at first when I saw Marc's email. I tried his >> example many times, with different values for shared_buffers. RSS column >> climbs until it reaches more or less the shared_buffers configuration. >> But, if I launch another psql, this process will have a much lower value >> on the RSS column. Shouldn't it get the RSS at the same value, even when >> the process starts ? > > No, that's exactly the point. Linux top includes in a process's > reported size its actual private space, plus however many pages of > shared memory that process has physically accessed so far. So any PG > backend that's doing a material amount of table access is going to show > an RSS that starts low and creeps up to roughly the size of your shared > memory block, quite independently of what its actual private space usage > is. It's just a matter of how many buffers it has had occasion to use. > > This is all pretty OS-dependent. Some systems don't count shared memory > at all (HPUX seems not to), and some other ones report a separate total > for shared memory so that you can mentally subtract it. > Forgot to thank you for the answer... Thanks :) -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
В списке pgsql-admin по дате отправления: