<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">I am surprised. Doesn't a current high-grade OS like Linux (maybe not Windows) routinely close the gaps in RAM by relocating running code and data? This is quite efficiently do-able in CPU architectures that use base/index/displacement memory addressing in the instruction set. This was introduced in the IBM 360 in 1964, carried forward into Intel x86, and probably used everywhere else since then.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"> <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">With base/index/displacement memory addressing, running code and data can easily be relocated by copying it to the new location and changing the contents of a few base registers, unlike the older architecture of entire linear addresses stored in the instructions that would require the whole program and data to have its addresses adjusted/rewritten after relocation.<br> <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">(Yes, if this sounds "academic", I have an M.Sc. (1975) in computer science.) :)<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"> <br></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font size="2"><span style="font-family:verdana,sans-serif">Hartmut W Sager - Tel +1-204-339-8331<br></span></font><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On 4 January 2016 at 11:32, Trevor Cordes <span dir="ltr"><<a href="mailto:trevor@tecnopolis.ca" target="_blank">trevor@tecnopolis.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It looks like a ISP DNS blockage caused one of our ps's to fall behind<br>
on and have around 5900 little sub-ps's pile up. Then a oom-killer<br>
triggered. oom-killer is actually wonderful in this case as it logged<br>
the state of everything to disk.<br>
<br>
Jan 4 08:55:29 kernel: [5384435.328060] Node 0 DMA: 2*4kB 1*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15744kB<br>
Jan 4 08:55:29 kernel: [5384435.329687] Node 0 DMA32: 14*4kB 43*8kB 62*16kB 35*32kB 7*64kB 16*128kB 67*256kB 21*512kB 2*1024kB 3*2048kB 20*4096kB = 123024kB<br>
Jan 4 08:55:29 kernel: [5384435.331315] Node 0 Normal: 15448*4kB 66*8kB 7*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 62432kB<br>
<br>
So it is fragmentation, or simple ram exhaustion, due to runaway small<br>
ps's due to blocked DNS. Time to rejig the app to handle DNS going down.<br>
:-)<br>
_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" rel="noreferrer" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</blockquote></div><br></div></div>