iarp Posted January 1, 2012 Posted January 1, 2012 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 Posted January 1, 2012 Posted January 1, 2012 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 Posted January 1, 2012 Posted January 1, 2012 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 Posted January 1, 2012 Author Posted January 1, 2012 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 Posted January 1, 2012 Posted January 1, 2012 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 Posted January 1, 2012 Author Posted January 1, 2012 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 Posted January 1, 2012 Posted January 1, 2012 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 Posted January 1, 2012 Author Posted January 1, 2012 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 Posted January 6, 2012 Posted January 6, 2012 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 Posted January 7, 2012 Author Posted January 7, 2012 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.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.