<div dir="ltr"><div><div><div>I managed to get my system in a state with dd test across a bunch of  client nodes (4k writes, many nodes in parallel, all to the same file -- by mistake, I meant to do many files), that all of the ttys except for /dev/console are stuck. It was showing signs of desparation swapping a few times, but it seems to have recovered from that. I have killed all of the write-intensive I/O and the host is mostly fine. Load has fallen, no residual I/O to disks, but the ttys that are not console are still stuck.<br><br></div>I had quite a few pauses in my vmstat output while the memory exhaustion from write load took place. In contrast, just can't bring the machine down with read load, as you might expect. The arc does an admiral job with the 72GB ram and can totally fill up the 10g pipes outbound.<br><br></div>It didn't lock up completely, but it came close, and there's some residual damage lingering with respect to the ttys.<br><br></div>(config = 2xquad core Intel Sandybridge CPU in Sun X4275 with 72GB ram and 12x4TB disks)<br><br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 5, 2015 at 12:15 PM, Chris Siebenmann <span dir="ltr"><<a href="mailto:cks@cs.toronto.edu" target="_blank">cks@cs.toronto.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> >> The hard part will be testing this. I'm not sure I have the HW<br>
> >> in-house to do it.  I may need illumos community help.<br>
> ><br>
> > Since we have a test environment where we can reproduce this and a<br>
> > high interest in seeing it fixed, we can test new kernel packages<br>
> > and so on.<br>
> ><br>
> > (If given specific howto instructions we can probably build test<br>
> > kernels from source, but we've never tried to do any OmniOS source<br>
> > building before so it may take us some time to get up to speed on<br>
> > that. It'd be much easier to take a prebuilt test kernel, drop it<br>
> > in, and go.)<br>
><br>
> I can turn around the whole world in an hour or less and provide<br>
> ONU images if your'e on 012 or 014. What revision are you running<br>
> currently? I can also help you get a build-illumos-omnios up and<br>
> running as well. Pick your favorite.<br>
<br>
</span> For now, the simplest thing is installable kernel images (I assume<br>
that's ONU images) for r151014, which is what our test environment<br>
is using now and what we'd wind up on with all of our production<br>
fileservers[*]. I won't be able to start any testing with the images<br>
until this afternoon at the earliest, so I don't think it's urgent to<br>
build them right away.<br>
<br>
 Thanks for all of this!<br>
<br>
        - cks<br>
[*: our production fileservers are currently at r151010 but we're<br>
    already looking at an r151014 upgrade. having this fix as part<br>
    of r151014 would make that upgrade definite, and there's other<br>
    things in 14 that we want, eg >16 group support over NFS.<br>
<div class="HOEnZb"><div class="h5">]<br>
_______________________________________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com">OmniOS-discuss@lists.omniti.com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/mailman/listinfo/omnios-discuss</a><br>
</div></div></blockquote></div><br></div>