If you so wish, you could run a script daily that'd look at some of these things, and try to shake some of the occupied memory loose. Here is an example of what I am running via cron jobs. It helped to stabilize things with WiFi a bit longer between reboots, although did not fully address WiFi that'd stop connecting after a while. So I ended up implementing almost daily reboots on top of that. You can add more of your commands to that script, of course, if you feel something else should be monitored.
Code:
admin@RT-AC86U-9988:/jffs/scripts# grep -E 'clearcache|reboot' post-mount
cru a clearcache "50 03 * * * /jffs/scripts/clearcache 2>&1 | /usr/bin/logger -t clearcache"
cru a ScheduledReboot "5 4 * * 1,2,3,4,5 reboot"
admin@RT-AC86U-9988:/jffs/scripts# cat clearcache
#!/bin/sh
ps wT |grep syslog |grep -v grep
ps wT |sort -n -k 3 |grep -v wred |grep -v roamast |tail -15
echo "wred count "; ps |grep "wred -B" |wc -l
uptime
free
echo "Dropping all caches now"
sync; echo 3 > /proc/sys/vm/drop_caches
#killall networkmap
free
Here is the output I get at 3:50 am:
Code:
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 8711 admin 13348 S {syslog-ng} supervising syslog-ng
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 8712 admin 212m S syslog-ng
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 9186 admin 212m S syslog-ng
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 1117 admin 14132 S /sbin/netool
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 1121 admin 14132 S /sbin/netool
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 9765 nobody 14524 S dnsmasq --log-async
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 1283 admin 15540 S amas_lib
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 7495 admin 15664 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 7496 admin 15664 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 7497 admin 15664 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 7498 admin 15664 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 7499 admin 15664 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 7504 admin 15664 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 1235 admin 18112 S conn_diag
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 1246 admin 18112 S conn_diag
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 1247 admin 18112 S conn_diag
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 2369 nobody 73384 S unbound -c /opt/var/lib/unbound/unbound.conf
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 2441 admin 75072 S ntpd -c /opt/etc/ntp.conf -p /opt/var/run/ntpd.pid -f /opt/var/spool/ntp/ntp.drift -s /opt/var/spool/ntp
Nov 29 03:50:00 RT-AC86U-9988 clearcache: wred count
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 2
Nov 29 03:50:00 RT-AC86U-9988 clearcache: 03:50:00 up 23:44, load average: 2.10, 2.31, 2.37
Nov 29 03:50:00 RT-AC86U-9988 clearcache: total used free shared buffers cached
Nov 29 03:50:00 RT-AC86U-9988 clearcache: Mem: 426020 397556 28464 1952 2632 113020
Nov 29 03:50:00 RT-AC86U-9988 clearcache: -/+ buffers/cache: 281904 144116
Nov 29 03:50:00 RT-AC86U-9988 clearcache: Swap: 2097148 31940 2065208
Nov 29 03:50:00 RT-AC86U-9988 clearcache: Dropping all caches now
Nov 29 03:50:00 RT-AC86U-9988 kernel: echo (14341): drop_caches: 3
Nov 29 03:50:00 RT-AC86U-9988 clearcache: total used free shared buffers cached
Nov 29 03:50:00 RT-AC86U-9988 clearcache: Mem: 426020 302684 123336 1952 204 23260
Nov 29 03:50:00 RT-AC86U-9988 clearcache: -/+ buffers/cache: 279220 146800
Nov 29 03:50:00 RT-AC86U-9988 clearcache: Swap: 2097148 31940 2065208
Thank you so much for providing this - which I will keep for use later. I won't go down this path yet, for two reasons:
1. Like others, I have been having WiFi (particularly 2.4Ghz refusing further connections - unless the router is hard rebooted) issues, at about 6 days after a reboot, from approx 386.10.x onwards, and particularly with 386.12.1 - 386.12.4. So to test, if this is a firmware or hardware issue, I decided to compare performance with Stock Asus (the latest available is 3.0.0.4.386_51915) and Merlin firmware - both of which have no add-ons or additions EXCEPT a config that blocks two specific IP's from Internet access and some reserved IP leases.
I tested 386.12.4 first, and like others, ran into 2.4Ghz Wifi issues after a while AS WELL AS my router crashing, with, as Merlin confirmed, an out-of-memory condition.
So to compare and contrast, I then loaded stock Asus 3.0.0.4.386_51915. This ran for 10 days fine - no issues with WiFi, and as I reported earlier, all things being equal, the Wifi signal (on 2.4Ghz and 5Ghz was tested, at different locations, as about -3db stronger). HOWEVER, with the stock Asus firmware, I could see that over about 5 days, free memory had dropped to about 40Mb, as memory use had shot up from an initial 278Mb to close on 485Mb. I am NOT a router firmware expert, but I could see that " httpds -s -i br0 -p 8443" had shot up to be using over 143Mb and was climbing ever higher*. So I previously mused if both firmwares have some sort of memory leak issue, and it is this that is causing some of the reported WiFi issues?
Whatever, I have now (because this is a compare and contrast test remember) returned back to 386.12.4, to see if the WiFi issues and crash/out-of-memory/huge usage by "httpds -s -i br0 -p 8443" etc return. If they do, then we will have a control (Asus stock 3.0.0.4.386_51915) against which we can compare.
2. While I could run 386.12.4 and simply run your script for nightly reboots (thanks again!) I am in the UK on a 80Mb FTTC circuit. Each time the connection goes down (on router reboot) the ISP (effectively OpenReach) will note the outage and will auto degrade my line sync rate (as they will think I have a dodgy copper pair from the Street cabinet into my property). So I'll get both an ever-more decreased bandwidth circuit AND also won't be comparing like with like on the firmware front - as one will be having a nightly reboot.
*An interesting footnote - that maybe something and nothing - is that after about day 5 on stock Asus 3.0.0.4.386_51915, when "httpds -s -i br0 -p 8443" was at 134M VSZ, suddenly, VSZ dropped to almost nothing and the WebUI showed I was back to 300Mb used again (from about 469MB). So I presumed, that some sort of cleanup/garbage collection had triggered compared to 386.12.4 - where it had obviously not (hence the out-of-memory crash). Doing a bit of research indicates (again I am NOT an expert) that there is a cleanup process triggered by OpenVPN BUT this is only supposition - because I am not running OpenVPN.
