aburgesser

Thanks Jorge. I was hoping there was a more generic solution to keeping a container well behaved. This does seem to be a container specific issue as I found a toggle for the issue between different workloads today.

I don't know the triggering change, but UHD H.265 10 bit encodes have started to make my unraid GUI and SMB become laggy, unresponsive, and time-out. This is new behavior that I've only noticed started last month+. It seems that 1080p still leaves the GUI and SMB working as expected. I have --cpu-shares=2 and --cap-add=SYS_NICE set. APP_NICENESS is set to 12. Encode uses the array as a source and a cache HHD (independent of the server SSD cache) as a destination. The server is running 7.1.4 I know I could pin away from core0 as a nuclear option, but I would rather not lose the encode performance. Please help.

You can use a watch folder for this, but are you sure you want to re-encode? You can remux those to a different container using mkvtoolnix and avoid generational losses.

Still looking for help with this. The configuration was working as I wanted before so I know it's not a completely unreasonable ask.

If you can ssh in, use the powerdown script. While a power cycle is more than you want, this will handle stopping the array.

In the past month or so, I've noticed that transcodes (via a handbrake container) on my server cause both the web GUI and SMB to become laggy, unresponsive, and time-out. The handbrake container previously had --cpu-shares=2 and APP_NICENESS set to 12. Looking for solutions I found that I should be setting --cap-add=SYS_NICE for niceness to work, so I did that and further bumped the niceness to 16. These steps had no apparent effect. I'm not aware of any setting/configuration I've modified that could cause these issues. The server is slightly overdue for an update (7.1.4). Any thoughts of how I could restore responsiveness while transcoding. I would rather avoid the nuclear route of denying handbrake the use of one of my CPU cores.

Unless you are at capacity, I would use the SSD as a secondary pool and back it's data up to the array. You don't compromise its write speed/features and you avoid exotic problems from an atypical configuration.

Ditto. I'm starting to wonder if I'm shadow banned. I can't even get acknowledgement, much less answers to my questions on the forums. Very disappointing when the community was one of the hyped features 5 years ago. Not hard stuff either. Things like "is this behavior expected" or if a proposed solution is worth trying.

No one publishes idle draw specs. Best you can do is see what people claim as idle power for different systems and/or apply rules of thumb. TDP would estimate max draw if it wasn't gamed so much. Neither Intel nor AMD is being reasonable with that spec anymore. The conventional wisdom is to slap an i3 on an ITX board if you want a power efficient Unraid box. There are more exotic solutions, but they will compromise on cost/convince/features.

Problem is you need the boot loader to be able to pull the GUID. LT has been resistant to calls for alternate binding (or even boot migration) for a while now. I would use the internal storage as a cache pool. If size is a concern, don't use it to cache the array shares, but instead host the appdata and system shares.

As always you need to declare use case. A 6700 can be quite a decent workhorse. If you can settle for the older Quick Sync, it will even transcode H264 and H265 (8-bit). I still think a 6300 is a fairly good Unraid CPU due to the ECC support. Just remember to drop the overclock for stability. 16 gb of RAM is serviceable until you want to run more than a bare bones VM. There are enough M.2 slots to run mirrored cache pools. A plus for redundancy. I've happily commissioned less capable systems myself.

Is it intended for Fix Common Problems to address files orphaned on a cache from a move between shares (https://docs.unraid.net/unraid-os/manual/troubleshooting/#mover-is-not-moving-files)? "Check for files stored within a cache pool that isn't allowed within a share's settings" implies it is, but it does not seem to catch such problems on my sever even when I set the plugin to always spin up disks for checks.

FYI, if you want to get really cheeky:

Haswell can support 10 series cards just fine. Looking at AoE2, it seems like it didn't have specific GPU requirements so any GPU you can pass through should be fine. I would troubleshoot your pass-through problems first. You will never get going if you can't get the GPU to the guest OS.

E5 systems are known to be moderately power hungry at idle. Newer hardware will typically be more power efficient. Honestly the jump from Sandy Bridge to Skylake will only save 10-30 W idle looking at references I see. Dropping the dGPU is an easy win though. The 6500 is a die shrink and you will loose 2 cores migrating to it. It also offers (an old version of) Quick Sync for transcoding. Dropping the dGPU and using a iGPU for live encoding would further reduce power needs. Keep in mind that Nvidia hardware encoding was typically better quality than Intel's for a given year. You may notice a drop in quality. In addition to loosing 8 threads, you will also need to drop ECC moving to the 6500. You may notice less horsepower if you do migrate. Honestly, if you are married to Skylake, I would give a look at finding a 6300. That gen was weird since the i3 cannibalized the low end Xeon market.