From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | flyusa2010 fly <flyusa2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: can shared cache be swapped to disk? |
Date: | 2011-01-05 01:40:55 |
Message-ID: | AANLkTin_RoQJrXqMDJMGuPVU6FW3Q_WssPMzqo2qMtbb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 4, 2011 at 2:52 PM, Martijn van Oosterhout
<kleptog(at)svana(dot)org> wrote:
> On Tue, Jan 04, 2011 at 09:51:05AM -0800, Jeff Janes wrote:
>> > Correct. The kernel ignores locking requests because it's a great way
>> > to DOS a machine. For example, mlock() of large blocks of memory is
>> > also not permitted for similar reasons.
>>
>> Does it ignore such requests in general, or only under certain situations?
>>
>> If the latter, do you know what those situations are?
>
> Well, not in general, but for shared memory it's ignored (not sure
> about if you're root). It used to be that shared memory was always
> locked, which sounds like a great idea, until people started abusing it.
>
> So now shared memory is on ethe same footing as other memory. Not sure
> where I read this, I know it came up several years ago. I think it
> changed back in 2.0 times.
>
>> RLIMIT_MEMLOCK exists, it has a small default hard limit, and only
>> root can increase that. If root has gone out of its way to grant the
>> postgres user a higher limit, the kernel should respect that, at least
>> up until the situation become truly desperate.
>
> Like I said, not sure about how it works for root.
I mean that root can increase it for *other* users.
I've done the experiment on kernel 2.6.31.5, as a non-root user, and
it looks like the kernel is respecting the SHM_LOCK.
On a 2GB machine I set shared_buffers to 1200MB and run pgbench -S
with scale of 80, and run it until it seems to be fully cached.
("top" doesn't distinguish between memory that has been requested but
never accessed, versus memory that has been accessed and then truly
swapped out to disk. So unless you first let it run to steady-state
before applying pressure, it is hard to interpret the results.)
Then I start up a Perl program that just perpetually loops through
~1.1 GB of memory.
If I SHM_LOCK postgres's memory, then only perl starts swapping. If I
don't lock it, then both perl and postgres start swapping.
Obviously there is a lot of territory not covered here, but it looks
like locking memory is respected in general. It still doesn't let you
benefit from using shared_buffers that are a large portion of RAM
(other than in silly test cases), and I don't know why that is, but
I'm now pretty sure it isn't due to swapping out the shared memory.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-01-05 01:59:57 | Re: Sync Rep Design |
Previous Message | Itagaki Takahiro | 2011-01-05 01:32:04 | Re: system views for walsender activity |