Re: Memory leak during delete with sequential scan
От | Roman Konoval |
---|---|
Тема | Re: Memory leak during delete with sequential scan |
Дата | |
Msg-id | CABcZEEDQF8dEj8OpXB7Ajt2KoK825kQE_B9YqqgWkDbTwQBmug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Memory leak during delete with sequential scan (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Fri, Sep 12, 2014 at 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Roman Konoval <rkonoval@gmail.com> writes: > > By private memory here I mean the sum of Private_Dirty and Private_Clean > > values for every memory segment in /proc/<pid>/smaps. > > Hm. I'm not terribly familiar with that API, but the notion that it > *ever* counts shared memory as "Private" sounds pretty bogus from here. > I'd suggest filing a bug against whichever kernel you're using. > This observation is doubled by a side note in this answer http://unix.stackexchange.com/questions/33381/getting-information-about-a-process-memory-usage-from-proc-pid-smaps > Note that a "share-able" page is counted as a private mapping until it is *actually* shared. i.e. if there is only one process currently using libfoo , > that library's text section will appear in the process's *private* mappings. It will be accounted in the shared mappings (and removed from the private > ones) only if/when another process starts using that library. It looks like this is by design and for kernel there is distinction between share-able and shared. Regards, Roman Konoval
В списке pgsql-bugs по дате отправления: