I have been trying to research this problem for a couple of weeks,  So far I have not found a viable solution.  My file transfers are up and down but not consistently so. I don't see a pattern to them within a transfer session.  What I mean by that is It doesn't appear to be RAM filling up then the slow down starts but who knows. Right now I am transferring large files (30GB each) from my local PC via a USB drive to the array,  I get maximums of 115MB sec. all the way down to zero and everything in between.  Here is what I have spec wise-

 

 

 

unRAID system:	unRAID server Pro, version 6.3.3
Model:
Motherboard:	Supermicro - X10SL7-F
Processor:	Intel® Xeon® CPU E3-1276 v3 @ 3.60GHz
HVM:	Enabled
IOMMU:	Enabled
Cache:	CPU Internal L1 = 256 kB (max. capacity 256 kB)
	CPU Internal L2 = 1024 kB (max. capacity 1024 kB)
	CPU Internal L3 = 8192 kB (max. capacity 8192 kB)
Memory:	32 GB (max. installable capacity 32 GB)
	P0_Node0_Channel0_Dimm0 = 8192 MB, 1600 MHz
	P0_Node0_Channel0_Dimm1 = 8192 MB, 1600 MHz
	P0_Node0_Channel1_Dimm0 = 8192 MB, 1600 MHz
	P0_Node0_Channel1_Dimm1 = 8192 MB, 1600 MHz
Network:	eth0: 1000Mb/s, full duplex, mtu 1500
Kernel:	Linux 4.9.19-unRAID x86_64
OpenSSL:	1.0.2k
P + Q algorithm:	NET (Registered protocol family 16 + avx2x4 (30406 MB/s)
Uptime:	3 days, 22 hours, 56 minutes, 56 seconds

 

 

I have been having the same issue on multiple point releases of Unraid so that may not be an issue.  I have checked TRIM and run it manually with no change.  My network is solid and since my peak rate is good I doubt that is an issue. 

 

Those are areas I have looked into.  I know some SSD'd have had issues in the past.  I have a 500GB Samsung 750 as my cache and have not heard anything chronic thus far.

 

Any help is appreciated.  I am attaching my diagnostic.

 

Thanks-

clearvideo-diagnostics-20170404-2012.zip

 

 

EDIT:  I just noticed something that may be a part of this.  When I get these dips that go to zero I am also noticing the web UI is completely unresponsive and if I am trying to start a movie in Plex it has difficulties and sometimes won't begin playback  At a minimum the buffering is significantly slower than normal.  I was just in a situation where all three activities were going at once and everything stopped for about 20-30 seconds.

 

EDIT #2:  Here is a link to a capture of the transfer process.  This one was more consistent than most.  What you can't see is I have one local Plex stream going during this and one remote stream.

 

EDIT #3 The first video wouldn't process on Youtube.  Take 2.

 

 

Edited April 7, 20179 yr by clearzero

"transferring large files (30GB each) from my local PC via a USB drive to the array" ... usually was bad idea.

I have seriously try/test USB stuff. Some USB-SATA adapter may run smooth but some may not.

 

In general, I don't think it is unRAID problem, suggest keep monitor the log, it may got some hints.

Edited April 5, 20179 yr by Benson

3 minutes ago, Benson said:

"transferring large files (30GB each) from my local PC via a USB drive to the array" ... usually was bad idea.

I have seriously try/test USB stuff. Some USB-SATA adapter may run smooth but some may not.

 

 

 

 

 

Thanks for the reply Benson.  Unfortunately I get this behavior regardless of the Chain.  If I go from Cache to array or even local drive to array it is the same.  I considered this but since the transfer speeds suffer in other configurations I figured it was probably not the issue.

I have 2 unRAID, no unresponsive issue, CPU just J1900 and G3250, but no VM or Plex.

Sorry for overlook you may talking Plex parallel run with Streaming and others in same time, it is not USB issue.

What I think is problem relate slow disk I/O of harddisk, disk array can't affort too much R/W access in same time.

Edited April 5, 20179 yr by Benson

Here is a second USB transfer.  Slightly different results but still having issues.

 

 

Third test.  This one is Cache to Array.  Similar results.  I have one docker running,

 

 

I'm having EXACTLY the same problem.  There is definitely an issue here, transfer speeds with unRAID are all over the place, even if copying from within a VM (on the cache drive) to another folder on the cache drive

 

I'm not sure if this is since a new release but it's been happening to me for weeks

 

Speeds range from 160MB/s to 3MB/s and below! Often it will just sit at zero for minutes at a time

Edited April 7, 20179 yr by sdamaged

So I've ran some more tests and found something odd

 

If i copy a movie file to my movie share (SMB) i will receive pretty horrendous transfer speeds as above

 

However, if i copy the file straight to the disk using a disk share, it's pretty much gigabit capped all the way

 

Makes no sense right?

2 minutes ago, sdamaged said:

So I've ran some more tests and found something odd

 

If i copy a movie file to my movie share (SMB) i will receive pretty horrendous transfer speeds as above

 

However, if i copy the file straight to the disk using a disk share, it's pretty much gigabit capped all the way

 

Makes no sense right?

 

Try with direct_IO enable, it reduces FUSE overhead.

OK i did this, and the speed was 90MB/s plus for the first 20GB of the 30GB movie, then it dropped down to 20MB/s and fluctuated between that speed and around 50MB/s

 

I checked my RAM usage and it's at 30% of 30GB

 

So, this did indeed help (thanks) but there is still an issue 

Here is something to try.  Install the 'Tweaks and Tips' plugin.  Then under the 'Tweaks' tab, set "Disk Cache 'vm.dirty_background_ratio' (%):" to '2' and " Disk Cache 'vm.dirty_ratio (%): " to '4'.  (These settings determine the amount of memory reservered for the queuing of writes to the hard disks.  Like most modern OS's, Linux writes are not done in real time but delayed until the disk(s) and OS is 'free'.  The default values appear to tailored for systems with small amounts of RAM.)

ok did this, transfer speeds start off good, and then half way through the copy, its down to 20MB/s - 40MB/s again

 

1 hour ago, sdamaged said:

OK i did this, and the speed was 90MB/s plus for the first 20GB of the 30GB movie, then it dropped down to 20MB/s and fluctuated between that speed and around 50MB/s

 

You won't get constant gigabit speed write for a large file unless you're using reconstruct mode (aka turbo write).

Turbo write is turned on 

Try using a PuTTY session and run htop  and see if anything shows up there... 

OK cool, what am i looking for in there?

Looking to see if any process spikes about the time when the showdown occurs.  That could provide a clue as to what is causing your problem.

Ok this is what i can see

 

 

I don't use Plex but I would be asking the question:  "What is Plex doing that it needs that much CPU?"  The little that I do know is that unless it is transcoding, it would also be accessing disks.

OK i stopped the Plex docker and re ran the copy

 

It seemed better.  Not a constant 115MB/s by any means though, hovering around 80MB/s which for an 11 disk array with turbo write, isn't wonderful

Edited April 7, 20179 yr by sdamaged

I don't think those speeds are out of bounds.  Remember there is a lot going on.  All of the other disks have to have the data read from them.  Both Parities must then be calculated and the new parity information written to both parity disks and the data written to the data disk.  I will set up a test here.  It could take up to a couple of hours for me to get back to you.

OK, I ripped a BluRay disk for testing purposes and I used ImgBurn to generate an ISO file that it wrote directly to the my two servers.  (ImgBurn is an old program that was written back in the days when CD burners did not an on-board memory buffer so any interruptions in data flow to the burner resulted in a coaster.  The core code is either assembly language or highly optimized C code.) 

 

The spec for my two servers are below.  Observe that the Test bed server is dual parity but the i3 does run that special matrix math instruction that dual parity needs for optimized performance.   (The CPU has to been released in the past couple of years to have that instruction!)  Both servers are virtually identical in hardware and software except for the hard disks used in them

 

Media Server:

I 12:52:35 Size: 42,199,671,651 bytes
I 12:52:35 Sectors: 20,605,316
I 12:52:35 Image Size: 42,200,727,552 bytes
I 12:52:35 Image Sectors: 20,605,824


I 12:52:37 Destination Free Space: 5,838,992,338,944 Bytes (5,702,140,956.00 KiB) (5,568,497.03 MiB) (5,437.99 GiB)
I 12:52:37 Destination File System: NTFS
I 12:52:37 File Splitting: Auto
I 12:52:52 Writing Image...
I 13:00:49 Operation Successfully Completed! - Duration: 00:08:12
I 13:00:49 Average Write Rate: 83,763 KiB/s (19.1x) - Maximum Write Rate: 128,537 KiB/s (29.3x)

Test Bed Server:
 

I 13:08:13 Size: 42,199,671,651 bytes
I 13:08:13 Sectors: 20,605,316
I 13:08:13 Image Size: 42,200,727,552 bytes
I 13:08:13 Image Sectors: 20,605,824


I 13:08:16 Destination Free Space: 1,119,405,600,768 Bytes (1,093,169,532.00 KiB) (1,067,548.37 MiB) (1,042.53 GiB)
I 13:08:16 Destination File System: NTFS
I 13:08:16 File Splitting: Auto
I 13:08:16 Writing Image...
I 13:14:56 Operation Successfully Completed! - Duration: 00:06:39
I 13:14:56 Average Write Rate: 103,287 KiB/s (23.5x) - Maximum Write Rate: 127,273 KiB/s (29.0x)

I would have expected the Media server to be faster because I think the disk data density on those hard disks is higher but perhaps is the location of the file on the hard disk that has affected the speed (closer to the center is slower).  But you can see that your current speeds are not usual.  I have ever really paid that much attention as most of the time the servers are delivering media to be watched rather than having data transferred to them. 

Edited April 7, 20179 yr by Frank1940

What speed do you get for Parity checks?   I would expect that with Turbo Write enabled the best you can get is slightly less than the Parity check speed.

Don't know you are querying but here are my figures:

Media server:  

Duration: 7 hours, 13 minutes, 26 seconds. Average speed: 115.4 MB/sec

Test Bed Server: 

Duration: 7 hours, 47 minutes, 27 seconds. Average speed: 107.0 MB/sec

Remember that the maximum speed figure is actually the speed of the initial data transfer to the server while the RAM cache is being filled.  Once that is filled, it slows down to the speed that the disks can write.  I would 'guess'  that the available RAM is in the neighborhood of 4-5GB and the total time actually includes the time to empty that bluffer after the data transfer is finished.  Yes, ImgBurn verifies that the all of the data is written before it says the job is completed and includes it in the total time.  (Most copy programs ignore that time!)

Many thanks for all your work here Frank, its much appreciated