<div dir="ltr">Here is a comment I added to a recent github issue re: node memory consumption and serval, suggesting enabling compressed swap as a psuedo-workaround.<br><br><a href="https://github.com/opentechinstitute/commotion-openwrt/issues/40#issuecomment-25683085">https://github.com/opentechinstitute/commotion-openwrt/issues/40#issuecomment-25683085</a><br>
<p style="margin-left:40px">... I suggested adding the "zram-swap" package presently in OpenWRT trunk
to the commotion packages feed, and then enabling swap in kernelconfig.
This would let you enable compressed swap memory on nodes, and ideally
make the memory limit somewhat softer (i.e. help nodes avoid OOM errors
and processes crashing).</p><div style="margin-left:40px">
</div><p style="margin-left:40px">So, specifically, do make kernel_menuconfig and make these selections:<br>
General Setup -> Support for paging of anonymous memory (swap) *<br>
Device Drivers -> Staging drivers -> Compressed RAM block device support *</p><div style="margin-left:40px">
</div><p style="margin-left:40px">This kernel config change can also be done via a patch, and such a
patch is buried somewhere in openwrt-devel listserv archives (i.e. when
the zram package was originally announced).</p><div style="margin-left:40px">
</div><p style="margin-left:40px">Then copy the zram_swap package from trunk into commotionfeed and enable it.</p><div style="margin-left:40px">
</div><p style="margin-left:40px">For my nodes with 32MB of RAM, I specify 6MB swap in /etc/config/system:</p><div style="margin-left:40px">
</div><pre style="margin-left:40px"><code>config system
...
option 'zram_size_mb' '6'
</code></pre><div style="margin-left:40px">
</div><p style="margin-left:40px">You can periodically check swap usage to ensure nothing is using excessive RAM:</p><div style="margin-left:40px">
</div><pre style="margin-left:40px"><code>root@nsm5-b:~# free
total used free shared buffers
Mem: 29184 24100 5084 0 2752
-/+ buffers: 21348 7836
Swap: 6140 0 6140
<br></code></pre>I should note this is only a <i>pseudo-workaround</i>, as it does not address the underlying issue of excessive RAM consumption. At best, zrap-swap would allow the node to avoid OOM errors, and furthermore detect it is in a low-memory state and actively do something about it (e.g. reboot).<br>
<br>I am running zram-swap as described above on WasabiNet nodes, both 5.8GHz mesh backhaul and 2.4GHz mesh APs, and I can confirm that certain processes <i>do not like to be swapped out</i>, freezing or behaving erratically as a result. hostapd, wpa_supplicant, olsrd, crond/busybox, and whatever your captive portal agent is (nodogsplash or coovachilli), all certainly shouldn't be swapped out. Possibly commotiond too, although I've not had opportunity to test that.<br>
<br><div>So, the zram_swap method described above lacks a bit in robustness. I think the <b>mlock</b> command can be used to prevent specific processes from being swapped out, although I'm uncertain of whether OpenWRT has this tool integrated.<br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 19, 2013 at 8:47 AM, Dan Staples <span dir="ltr"><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Dan,<br>
<br>
Disabling Serval won't affect the splash screen, but it will prevent<br>
local app announcements from automatically propagating. Here's how to<br>
turn it off/disable it:<br>
<br>
/etc/init.d/serval-dna disable && /etc/init.d/serval-dna stop<br>
<br>
Let me know if that doesn't solve the problem!<br>
<br>
best,<br>
Dan<br>
<div class="im"><br>
On 10/19/2013 04:56 AM, Daniel Hastings wrote:<br>
> I was wondering if there was a quick fix to the memory issue that causes<br>
> the nodes to crash in DR2. I know that Dan had mentioned that you could<br>
> disable serval even though it disabled the splash screen. Even that is<br>
> the case I'm ok with it as long as if fixes the memory issue for the<br>
> time being. Any quick simple explanation would be extremely helpful. We<br>
> are having some serious issues with nodes crashing repeatedly on end<br>
> over here.<br>
><br>
> Thanks again!<br>
><br>
> Dan<br>
><br>
> --<br>
</div>> *Dan Hastings*<br>
> /Abaarso School Computer Science Department/<br>
> <a href="mailto:dhastings@abaarsotech.org">dhastings@abaarsotech.org</a> <mailto:<a href="mailto:dhastings@abaarsotech.org">dhastings@abaarsotech.org</a>><br>
><br>
><br>
> _______________________________________________<br>
> Commotion-discuss mailing list<br>
> <a href="mailto:Commotion-discuss@lists.chambana.net">Commotion-discuss@lists.chambana.net</a><br>
> <a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dan Staples<br>
<br>
Open Technology Institute<br>
<a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a><br>
OpenPGP key: <a href="http://disman.tl/pgp.asc" target="_blank">http://disman.tl/pgp.asc</a><br>
Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9<br>
_______________________________________________<br>
Commotion-discuss mailing list<br>
<a href="mailto:Commotion-discuss@lists.chambana.net">Commotion-discuss@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
314-246-9434<br></div>
</div>