Rolling back to 4.7 from 5b14? + RAM issue

[iarp]

Long story short, I am currently on 5.0-beta14

 

I'm having a few issues I'm unsure if 4.7 would fix. I originally built the machine with 1GB of ram and noticed when I first started testing with unRAID that it ran around 400MB which seemed fine to me at the time. Yesterday i noticed it was acting very sluggish and overall slow from all aspects, i checked 'top' in ssh and it reported only 12MB's worth of RAM free.

 

I restarted the machine without unmenu, cache_dirs or simpleFeatures thinking maybe one of those was killing the memory, but still 12-20MB's free ram. So i stuck in another stick of 1GB for a total of 2GB's and guess what, 25-50MB's ram free. The numbers in 'top' don't add up to the amount of used memory listed.

 

Is downgrading to 4.7 a good idea?

Is this ram issue known/potentially-beta-only-issue?

[daniel.boone]

Bulk of the memory is used as a disk buffer. What you noticed is normal. Downgrading won't change it.

 

After you still restarted would you say the system is still sluggish?

[graywolf]

When you do the free cmd....are you looking at the first line or the -/+ buffers/cache line?

 

*nix will use all the memory it can for buffers/cache and will give it up if needed. If you have plenty of memory free on the -/+ buffers/cache line then you are fine.

 

root@Tower:/mnt/user/pmm -> free

                  total        used          free    shared    buffers    cached

Mem:      3888080    3779184    108896          0    221332    3132604

-/+ buffers/cache:      425248    3462832

Swap:            0          0          0

 

[iarp]

Bulk of the memory is used as a disk buffer. What you noticed is normal. Downgrading won't change it.

 

After you still restarted would you say the system is still sluggish?

 

Sometimes I find during certain situations the webui crawls to a dead stop. Such as stopping the array, the webui just stood there in chrome with the busy signal for 15minutes. Eventually I had to go into unMENU on port 8080 and stopped the array, I'm then forced to restart because the normal webui just won't load.

 

root@storage1:~# free
             total       used       free     shared    buffers     cached
Mem:       2073504    2019228      54276          0      21480    1902900
-/+ buffers/cache:      94848    1978656
Swap:            0          0          0

[daniel.boone]

If stopping the array is the only issue I would suspect a running process is keeping the array from shutting down correctly. A forced shutdown usually means a parity check follows.

 

Exactly what add ons are you using? Check unmenu add ons too. Maybe you have something set to autostart in unmenu that is overlooked. Easy to do when all the add on scripts are loaded. What's in you go file as well?

[iarp]

It's not just stopping the array, that was just the one that came to mind because it has happened so often.

 

My go file:

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &


cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c 

echo nameserver 192.168.2.1 >/etc/resolv.cong
echo 192.168.2.205 storage1 >>/etc/hosts

unraid_notify start

/boot/cache_dirs -d 4 -m 3 -M 10 -w

/boot/unmenu/uu
installpkg /boot/packages/simpleFeatures-0.9b-unraid-speeding_ant.tgz
installpkg /boot/packages/powerdown-1.02-noarch-unRAID.tgz

cp -f /boot/config/.screenrc /root/

 

The only things I've personally set to reinstall for unmenu is screen and bwm-ng

[daniel.boone]

I think the name server line has a typo...shouldn't it be .conf?

 

Rename your go file to go.bak and create a new go file with just the first 3 lines of the code you posted. Reboot and see if the system is still sluggish.

 

Besides stopping the array when else does the system seem slow?

[iarp]

It was just the webui generally being slow, trying to change share settings could take a while, or trying to browse the shares via the webui, adding users ...etc

 

Here is 'free' after restarting with the new go file

root@storage1:~# free
             total       used       free     shared    buffers     cached
Mem:       2073504     271408    1802096          0       4508     204604
-/+ buffers/cache:      62296    2011208
Swap:            0          0          0

 

After the restart the webui is much more responsive to everything. I looked at the resolv.conf file after a reboot and it already picked up the 192.168.2.1 address automatically so i don't think i'll readd that line to the go file. Is the /etc/hosts file worth doing to?

 

I'm currently manually starting each package one-by-one and running 'free' command to see if something starts eating a lot of memory.

[daniel.boone]

Glad things are looking better. A host entry is good but the entries must be for static ips only. When things change you have to go back and verify your original entries or you will encounter issues.

 

 

 

 

[iarp]

Things seem to be going a lot better. Not sure what's changed exactly but something I did or a package i installed before was slowing everything down.

 

Before it was writing at only about 10-15MB/s and about 30 to cache but I'm not sure what has changed but I am getting 60MB/s to cache drive (7200) and 30MB/s to array from cache, all array disks are 5400.