June 7, 201610 yr So I have an 8 disk array, 2 parity, all 8 drives are 3tb reds with 2 samsung 850 pro cache drives. this install is about 1 week old. added tips and tweaks plugin, powerdown package 2.20, community applications and fix common problems plugins. also have a small handful of dockers from linuxserver.io, all working ok. things seemed slow when transfering from SSD to the array. i tested file transfers using SSH and MC and the speeds would burst at around 100MB\s and then immediatly drop off to sometimes less than 10MB\s. tested all 8 drives and it seems to be slow when reading \ writing to any of the drives, not just 1 particular. hardware specs are high (see system information) - running the drives through an IT flashed LSI SAS2008 inside a supermicro case. running a parity check right now and its been over 12 hours and its sitting at 25MB\s - is this a beta issue or hardware issue? Model: SuperMicro M/B: Supermicro - X10SL7-F CPU: Intel® Xeon® CPU E3-1231 v3 @ 3.40GHz HVM: Enabled IOMMU: Enabled Cache: 256 kB, 1024 kB, 8192 kB Memory: 32768 MB (max. installable capacity 32 GB) Network: bond0: fault-tolerance (active-backup), mtu 1500 eth0: 1000Mb/s, Full Duplex, mtu 1500 eth1: not connected Kernel: Linux 4.4.6-unRAID x86_64 OpenSSL: 1.0.2g Uptime: link-diagnostics-20160607-0928.zip
June 7, 201610 yr Community Expert UID PID PPID C STIME TTY TIME CMD nobody 4877 4600 33 Jun06 ? 04:03:09 ./Plex Media Server Looks like plex is running and considerably using the CPU, if it's scanning disks for media or doing any other disk operation it's normal for the parity check or any write operation to be much slower.
June 7, 201610 yr Author good find, but even turning off ALL dockers i get the same slow results - not just slow parity, every transfer within the array is slow. i stopped all dockers and will post another diag in a minute UID PID PPID C STIME TTY TIME CMD nobody 4877 4600 33 Jun06 ? 04:03:09 ./Plex Media Server Looks like plex is running and considerably using the CPU, if it's scanning disks for media or doing any other disk operation it's normal for the parity check or any write operation to be much slower.
June 7, 201610 yr Author here is the diagnostics with all dockers stopped, and the parity check sitting at about 94% (nothing else is running) link-diagnostics-20160607-1211.zip
June 7, 201610 yr Community Expert Changing these should improve the parity check speed, Settings > Disk Settings: Change md_sync_window to 2048 and md_sync_thresh to 2000. You can change them during the check, if it works the speed increase should be noticeable after a few minutes.
June 7, 201610 yr Author well, it did seem to speed up a bit but it finished before i could gauge anything. after those changes, and the parity finished with dockers all still stopped, i tried a transfer using MC between 2 disks. no matter the file size (yes this one is by far the largest) it starts off nice and quickly slows. check out this quick video showing the result
June 7, 201610 yr Community Expert 50-60MB/s is normal writing speed to the protected array, initial speed is due to RAM caching, you can enable turbo write to improve that, disadvantage is that all disks will spin up for writes.
Archived
This topic is now archived and is closed to further replies.