So I recently rebuilt my system with the intention of going to ESX....  unfortunately I got pink/purple screens of death so I never got around to actually getting unraid running under ESX.

 

I just ended up booting with the unraid USB key until I have time to fix it.  The system has 1x8gb ECC at the moment and I seem to be getting OOM errors. 

 

I'm a little unlcear if reducing the usable memory will give me more or less problems.....  I'm only using between 1-2gb the rest is cached.  Addons are Plex and Slimserver...  The system ran out of memory while copying files from one disk to another using midnight commander.  No idea what was happened the first time,  maybe transcoding with plex since I wasn't home at the time.

 

Any suggestions on what to do or try next would be great.

My guess is you ran out of low memory so 4GB vs 8GB probably doesn't make a difference.  Separating the Plex and Slimserver off into another VM in ESX might give you better results since you could limit your plugins in unRAID to just NAS related plugins and put the transcoding and media serving plugins in a separate VM.  If unRAID 64bit was available you probably wouldn't have problems either.

 

With that said.  If a log was posted that shows the OOMs you might get advice from those more knowledgeable then me as they might be able to see something to advise you on.

Are you running cache_dirs?

Where is Plex and Slimserver installed?

If they are on the root ramdrive then that could chew up some ram.

 

Someone posted that the basic housekeeping of the extra ram eats up some memory. You could try limiting ram with a boot parameter.

 

add mem=4095M  to the append line in your syslinux.cfg

 

I've found issues usually crop up when you have a ton of small files and are traversing the file systems frequently.

Thanks for the replies,  I'm running both apps from the cache drive and I gave up with cache_dirs a long time ago as that was causing me to run out of ram frequently.

 

I'll try the boot parameter and see if that makes any difference.

 

If I don't get any joy there then I'll go back to plan a and have unraid running addon free in a VM and run any apps in a separate full blown linux VM.

 

the main thing that puzzles me is I run the same add-ons on my HP Microserver and that only has 2gb of ram....  the big difference I guess is that box is only up for a few hours everyday while I'm actually at home so maybe it's just a case of rebooting the main server more frequently.

You could try dropping the cache before and after the mover runs.

Or after any frequent job that traverses the whole filesystem.

 

See this thread.

 

http://lime-technology.com/forum/index.php?topic=28920.msg258373#msg258373

 

i used to have all sorts of problems with the daily execution of updatedb from the slocate package.

I had to do something like this to drop the cache before and after.

 

I also had to do this to my rsync backup scripts.

 

For this particular case,

it depends on how many files you have vs how many times you traverse the filesystem.

Good idea,  I do have quite a large array and plex probably pokes most of the file system every few hours.

 

I'm already using a custom mover script which doesn't run if I'm watching media,  although this probably isn't needed anymore now I have a stupidly over specced CPU in the box

 

Thanks again for the input.

let us know how it works out.

Maybe we could get Tom to update the mover to do these few extra lines if a certain flag file exists somewhere.

 

 

Well I added  :-

 

echo 3 > /proc/sys/vm/drop_caches

 

Before and after the rsync in my mover script and I haven't had any processes killed in the last two weeks.  Uptime was 35 days last time I had issues and I'm on 17 now so maybe not conclusive yet.

Thanks, keep us informed. If it works for you, then maybe we can have an update to the mover script.

If a flag file exists in a specific location, drop the caches before and after.

Well I added  :-

 

echo 3 > /proc/sys/vm/drop_caches

 

Before and after the rsync in my mover script and I haven't had any processes killed in the last two weeks.  Uptime was 35 days last time I had issues and I'm on 17 now so maybe not conclusive yet.

 

Marking as solved,  no more issues or reboots since adding this to my mover script.  Thanks chaps.

Well I added  :-

 

echo 3 > /proc/sys/vm/drop_caches

 

Before and after the rsync in my mover script and I haven't had any processes killed in the last two weeks.  Uptime was 35 days last time I had issues and I'm on 17 now so maybe not conclusive yet.

 

How does one go about modifying the mover script so the changes stick around after boot?  I can't seem to figure this out...

Well I added  :-

 

echo 3 > /proc/sys/vm/drop_caches

 

Before and after the rsync in my mover script and I haven't had any processes killed in the last two weeks.  Uptime was 35 days last time I had issues and I'm on 17 now so maybe not conclusive yet.

 

How does one go about modifying the mover script so the changes stick around after boot?  I can't seem to figure this out...

 

Never mind... I think I figured it out.

Interesting. I solved a similar problem with the mover causing OOM-killer events. It was not running out of low memory, but low memory being too fragmented that a large enough chunk was not available. See the thread WeboTech linked. A swapfile worked for me, it seems to reduce fragmentation, as swapping stuff out and back in has a defragmenting effect.

 

It would be interesting to know if your problem really is with low memory. Perhaps you would care to post a log section from one of your OOM-killer events.