I'm only running one plugin, sabnzbd, and after a certain amount of weeks running it consistently dumps due to an out of memory issue.

 

I've found the following threads but don't seem to understand the solution involved:

 

http://lime-technology.com/forum/index.php?topic=22621.0

http://lime-technology.com/forum/index.php?topic=20013.msg200115;topicseen#msg200115

 

Is this the command to invoke unRAID to free its cached memory?

echo 3 > /proc/sys/vm/drop_caches

 

If so, how often should it be run?

 

 

Unraid 5 is running on a VM with 4GB of allocated memory.

If so, how often should it be run?

 

Perhaps anytime there is a very large filesystem scan.

Perhaps after the mover script.

 

Are you running cache_dirs?

Pruning what that script sees could help.

 

Not running cache_dirs, was thinking of just putting it in cron.weekly.

Even after clearing the caches the python dumps are still happening:

 

root@tower:~#
             total       used       free     shared    buffers     cached
Mem:       4145760    2582080    1563680          0      60056    1724484
Low:        864984     821224      43760
High:      3280776    1760856    1519920
-/+ buffers/cache:     797540    3348220
Swap:            0          0          0
root@tower:~# echo 3 > /proc/sys/vm/drop_caches
root@tower:~# free -l
             total       used       free     shared    buffers     cached
Mem:       4145760    1176064    2969696          0      58648     320364
Low:        864984     819260      45724
High:      3280776     356804    2923972
-/+ buffers/cache:     797052    3348708
Swap:            0          0          0

 

It does not appear as though the command is freeing much of the low memory, should I add it to /etc/cron.hourly?

What happens if you stop and restart sabnzbd.  Maybe there's a memory leak in it somewhere.

 

 

Is the app installed on your ram drive or cache?

Is it using tmp space or any directories on your root/ram drive?

anything growing in /var somewhere ?

Thanks for the help WeeboTech,

 

du -hs /var/
9.3M	/var/

 

In fact sabnzbd is installed on a drive I have mount outside the array via a mount command in my go script. The drive houses a lot of temporary download files, etc.

 

That drive is only 26% used. Probably the issue? But why so?

So I kept on issuing the "echo 3 > /proc/sys/vm/drop_caches" command while restarting sabnzbd and woke up this morning to a frozen unraid system.

 

I couldn't log in via telnet and the ESXi console to the unRAID vm was frozen as well, had to reset and not running a parity check.

 

I have this in my go file:

# emhttp will never get killed by unix as a result of lack of memory:
pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -17 > /proc/$PID/oom_score_adj; done

 

and like i said sabnzbd is installed on an outside drive which mount with:

mkdir -p /mnt/disk/downloads
mount -t ext2 /dev/disk/by-id/scsi-SATA_Hitachi_HDT7210_STF60xxxxxx-part2 /mnt/disk/downloads

 

I also export the mounted drive via nfs, not just if that's relevant

echo \"/mnt/disk/downloads/opt/unRAID/incoming\" '-async,no_subtree_check,fsid=90' '*(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports-
/usr/sbin/exportfs -r

 

I believe the unRAID system crashed when I was moving in some movies to one of the shares, I have a script on another vm that mounts the share and does the moving. Could it be the amount of files? I do not have a swapfile.

 

I guess both sabnzbd and unraid crashing are related.

that drive is only 26% used. Probably the issue? But why so?

I do not believe the amount of used space would be the cause of the problem.

 

Makes me think there was some kind of deadlock with memory or there was some kind of issue with IO.

 

You should only have to do the drop cache after you stop the sabnzbd.

Then start sabnzbd.

 

Check your free -l before and after.

 

if unRAID is locking up that's cause for concern. What version are you running?

Version 5.0, I wished I could have grabbed a log but the system was completely frozen. An IO issue would be probable.

 

Also, on under note, would reserving the memory in the Virtual Machine Properties of ESXi have any effect?

Also, on under note, would reserving the memory in the Virtual Machine Properties of ESXi have any effect?

 

I do not know.

 

Scan the board for a script called keeplogs.sh this alters the syslog.conf file to save the messages locally to help track lockup conditions like this.  Since you are running esx, have you considered running the application in it's own VM using unRAID as the fileserver only.

I've been slowly moving plugins off of the unRAID VM, I figured to keep sabnzbd on there because I chose to mount a drive outside the array and have the downloads go straight there. Maybe I should consider moving sabnzbd to another vm as you suggest. But still odd that it would bring down the whole VM, that's definitely not cool.

 

Thanks for the feedback WeeboTech

 

Maybe time to try out nzbget

Also, on under note, would reserving the memory in the Virtual Machine Properties of ESXi have any effect?

Scan the board for a script called keeplogs.sh \

 

Did a search for this script, having problems tracking it down.

 

I noticed your post here: http://lime-technology.com/forum/index.php?topic=18486.msg165497#msg165497, worth doing?

So I kept on issuing the "echo 3 > /proc/sys/vm/drop_caches" command while restarting sabnzbd and woke up this morning to a frozen unraid system.

 

I couldn't log in via telnet and the ESXi console to the unRAID vm was frozen as well, had to reset and not running a parity check.

 

I have this in my go file:

# emhttp will never get killed by unix as a result of lack of memory:
pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -17 > /proc/$PID/oom_score_adj; done

 

That line was for unRAID 4.7.  The newer kernel on 5.0 uses a different /proc target and a different value set.

(now +1000 through -1000 vs. +17 through -17 on older kernel versions)

 

On 5.0 I personally use in my go script as I put it in place with the "if" statement so I could go back and forth between versions of unRAID:

Today, on unRAID 5.0 final, only the two lines in blue are needed.

 

if [ -e /proc/1/oom_score_adj ]

then

  pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done

  pgrep -f "smbd" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done

else

  pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -17 > /proc/$PID/oom_adj; done

  pgrep -f "smbd" | while read PID; do echo -17 > /proc/$PID/oom_adj; done

fi

 

 

Now, this will not solve your memory issue, but using a value of "-17" instead of "-1000" has hardly any effect"

Thanks for the tip.