It's an interesting question. I asked around at work and here are the responses:<div><br></div><div>David Owen:</div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">One method requiring a lot of work would be to set resource limits on<br>

everything else on your system to guarantee that SSH always has<br>resources available.  This would also significantly under-commit or<br>under-utilize your system.<br><br>I've never actually had problems with SSH except it being pushed into<br>

swap by a memory hog, and the system becoming generally unresponsive as<br>a result (theoretically, resource limits *would* help with that).<br><br>It seems like there ought to be a way to tackle it from the opposite<br>
direction though, similar to locking pages in RAM.<br>
</span><br></div><div>-----------</div><div><br></div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">David Owen:<br><div class="im" style="color: rgb(80, 0, 80); ">

> I've never actually had problems with SSH except it being pushed into<br>> swap by a memory hog, and the system becoming generally unresponsive<br>> as a result (theoretically, resource limits *would* help with that).<br>

><br>> It seems like there ought to be a way to tackle it from the opposite<br>> direction though, similar to locking pages in RAM.<br><br></div>In this scenario you have to consider that getting an interactive shell<br>

is often the hard part.  Once you get past SSH auth on a loaded system<br>(reading in pubkeys off disk, etc) you then have to page in bash.  Once<br>you're at bash on a thrashing system, now you have to get a program like<br>

/bin/ls in core (or at least page in the appropriate bash code to do<br>something like "echo *").<br><br>One approach (of supremely dubious general utility) is to make sure the<br>system has no swap.  In an out-of-memory situation, sometimes the si/so<br>

load turns what should be an immediate kill into an hour-long pagefest.<br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div>

<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Nick Moffitt</span></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>

</span></font></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; "><div>

-----------</div><div><br></div></span></span></div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div class="im" style="color: rgb(80, 0, 80); ">

On 28 June 2011 10:25, Nick Moffitt wrote:<br>> One approach (of supremely dubious general utility) is to make sure the<br>> system has no swap.  In an out-of-memory situation, sometimes the si/so<br>> load turns what should be an immediate kill into an hour-long pagefest.<br>

<br></div>When I first had an SSD laptop, I tried using no swap, and I found<br>that when it ran low on memory, it quite abruptly became totally<br>unusable, whereas with swap you get a bit of a softer landing where<br>the machine is slowing down but still responsive enough that you can<br>

kill something.  I guess this is because it's having to kick out<br>program text that's still relatively hot, because it has nowhere to<br>put even relatively cool heap memory.  Of course swapping to SSD will<br>
be a bit different to magnetic disks.<br>
<br>It seemed like Ubuntu out of the box does not have an OOM killer that<br>intervenes before the machine bogs down.  So I think that old advice<br></span><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">is not very good today.<br>

</span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Martin Pool<br>

<br></span></div><div></div><div><div class="gmail_quote"><meta charset="utf-8"><div>-----------</div><div><br></div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div class="im" style="color: rgb(80, 0, 80); ">

On Tue, 2011-06-28 at 09:25 +0000, Nick Moffitt wrote:<br>> David Owen:<br>> > It seems like there ought to be a way to tackle it from the opposite<br>> > direction though, similar to locking pages in RAM.<br>

><br>> In this scenario you have to consider that getting an interactive shell<br>> is often the hard part.  Once you get past SSH auth on a loaded system<br>> (reading in pubkeys off disk, etc) you then have to page in bash.  Once<br>

> you're at bash on a thrashing system, now you have to get a program like<br>> /bin/ls in core (or at least page in the appropriate bash code to do<br>> something like "echo *").<br><br></div>Could you mark sshd as a realtime process?  Would bash then inherit the<br>

priority? (and down the stack)<br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Ted Gould</span></div>

<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><meta charset="utf-8"><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; "><div>

-----------</div><div><br></div><div>I'll let you know if anything else comes up, but in essence, I went to some experts and got a lot of head scratching. The implication is that there is no easy solution to this.</div>

</span></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">

On Mon, Jun 27, 2011 at 4:39 PM, Kenneth Younger <span dir="ltr"><<a href="mailto:kenny@sheerfocus.com">kenny@sheerfocus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I had a sever crush under load the other day, so much so that it made SSHing into the box impossible. There's got to be a way to keep that admin tool available until the end, right?<br><br>A cursory search of google found nothing - of course I might be using the wrong keywords...<br clear="all">


<br>-Kenny<br><font color="#888888"><br>-- <br><font color="#888888">Kenneth Younger III<br>Founder, Sheer Focus Inc.<br>e: <a href="mailto:kenny@sheerfocus.com" target="_blank">kenny@sheerfocus.com</a><br>p: (515) 367-0001<br>

t: <a href="http://twitter.com/kenny" target="_blank">@kenny</a></font><br>

</font><br>_______________________________________________<br>
Cialug mailing list<br>
<a href="mailto:Cialug@cialug.org">Cialug@cialug.org</a><br>
<a href="http://cialug.org/mailman/listinfo/cialug" target="_blank">http://cialug.org/mailman/listinfo/cialug</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Matthew Nuzum<br>newz2000 on freenode, skype, linkedin and twitter<br><br><p>"Opportunity is missed by most people because it is dressed in overalls and looks like work." -Thomas Edison</p>

<br>
</div>