Straight from the start - I use the recommended disk configuration:
4 x Western Digital 3TB RED (RAID 5)
ReadyDLNA does not really. During longer Kopiervorgaenge should turn definately DLNA as the box otherwise completely asleep and only every few minutes enough IO auftreibt to "respond" to requests for, and then again to start a Dornroeschenschloss sleep for the next few minutes. Inotify should one turn in the DLNA-config on each case, as the box you can never deal - then gehts so halfway, but this is not acceptable in my opinion, for a streaming server, because as new streaming content not reliably detected will and possibly a DLNA server restart is required, then the box will deal with again for the next hours.
Then I noticed that SWAP is practically not used. Only when everything goes to the end (and 512 MB of RAM nowadays are really not much), unneeded process ballast is swapped to disk (SWAP) or croak the box and is then only more power-hungry without benefits. A solution I found - I have asked the swappiness in /etc/sysctl.conf from "0" to "60" (= Linux default) and even the swap space has been used well-behaved. From this point the box functioned then also clean at last.
But it was ultimately unsustainable:
If you then (like me) has DLNA turned and swap enabled, the box is to work far from it. It is the immature Btrfs filesystem on the data plate (with me> 8 TB) in order to be able to simply cyclically snapshots. The idea is good, but the implementation is absolutely besch..eiden. Exactly the Btrfs processes themselves are then also, can completely freeze the box as soon as the disk space reaches the 70% mark (!!!!!). If this limit is reached, then one obtains a warning email (if you have set this monitoring) and then work at all nothing. Almost all processes sleeping to death ("[D] ead"):
--- ======================================== ---
D 233 [kswapd0]
D 828 / lib / systemd / systemd-journald D 1355 [Btrfs transactionSHUTTLE] D 7343 [Btrfs Endio-wri] D 7420 [Btrfs Endio-wri] D 7428 [Btrfs Endio-wri] D 7493 sync
D 7502 php5 -c -d /etc/php5/apache2/php.ini error_reporting = '~ E_ALL' -r print ini_get ("session.gc_maxlifetime");
D 7597 / usr / sbin / smbd
D 7604 / usr / sbin / smbd
D 7610 / usr / sbin / smbd
D 7614 / usr / sbin / smbd
D 7619 / usr / sbin / smbd
D 7624 / usr / sbin / smbd
D 7627 / usr / sbin / smbd
D 7631 / usr / sbin / smbd
D 7632 / usr / sbin / smbd
D 7642 / usr / sbin / smbd
D 7651 / usr / sbin / smbd
D 7658 / usr / sbin / smbd
D 7664 / usr / sbin / smbd
D 7667 / usr / sbin / smbd
D 7672 / usr / sbin / smbd
D 7680 / usr / sbin / smbd
D 7694 / usr / sbin / smbd
D 7699 / usr / sbin / smbd
D 8815 [flush-btrfs-1] D 11058 / usr / sbin / apache2 -k start
D 23098 [nfsd]
D 23099 [nfsd]
D 23100 [nfsd]
D 23101 [nfsd]
D 23102 [nfsd]
D 23103 [nfsd]
D 23104 [nfsd]
D 23105 [nfsd]
--- ======================================== ---
The remaining processes have been carried away, because you can not write to the disk.
Note: Only to obtain this list, I had to wait stopped in 43 minutes. I have subsequently commandline statement used to create the list of "death-sleeping" processes:
# For HH in $ (seq 1 1 10); ps do -eo state, pid, cmd | grep "^ D"; echo "--- --- ========================================"; sleep 5; Done
With my experience, I am not alone:
[...]
Conclusion: Stay away from THIS SPAR NAS - before reaching the 70% -Schwellwertes can work more or less with the crate, but then is Feierabend. Linux ignorant should rely on no case for this device - it is absolutely immature !!!!!
I'll return the box ...
