Re: BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always)
От | Pavan Deolasee |
---|---|
Тема | Re: BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always) |
Дата | |
Msg-id | 2e78013d0812110035q3a4378d5n6eed43c63817c2d8@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always) ("Scott Carey" <scott@richrelevance.com>) |
Ответы |
Re: BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always)
Re: BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always) |
Список | pgsql-bugs |
On Thu, Dec 11, 2008 at 5:37 AM, Scott Carey <scott@richrelevance.com> wrote: > > > Run top, and note the largest value of the "SHR" column on all postgres > processes. Now execute the os cache eviction. Check the remaining cached > memory. > Note that it is now larger than the baseline by essentially the exact size > of the postgres shared memory. > Isn't the shared memory on Linux non-swappable, unlike Solaris where you have an option to make is swappable ? As and when shared memory pages are accessed, they are allocated and can not be swapped out. I don't know if these pages are counted as part of the OS cache, but assuming they are, I don't see any problem with the above observation. May be you can try to write a C program which creates, attaches and accesses every page of the shared memory and check if you see the same behavior. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: