I'm experiencing slow downs in my transfers from *any pc* to my unraid server. Ive had this issue before (a year ago) but I also haven't transferred a lot of files since then, until a week ago, which is when I saw this happening again.

 

In this instance I was transferring a 2 GB file from my Windows PC (SSD, 1Gbit/s network) to my NAS, to a share that has cache enabled (850 EVO, 70% free). During this time there were no other heavy processes running (<5% CPU usage). If I'd wait a few minutes after a slower transfer, the next one would (at least) begin with a 125MB/s again. Which made me think it might be related to my limited amount of RAM (8 GB), although Unraid is showing me a ram utilization of only 39% (this is with a few Dockers and no VMs).

Where would I start looking?

Thanks in advance!

My configuration:
i3-7100, 2c4t @3,9GHz
1x 8 GB DDR4 RAM
3 x 3 TB + 2 x 8 TB (total disks, in single-parity, xfs) + 250 GB SSD (btrfs) as cache
1Gbit ethernet (no-one else was using it during the previously mentioned transfer)

Edited March 8, 20206 yr by ssh
Solved

Transfer graph suggests LAN is working correctly and first few GBs are fast because they are cached to RAM, after that looks like your cache can't keep up.

 

Try enabling turbo write and writing directly to array to compare.

@johnnie.black

I just did a new transfer to a share with cache enabled => 112MB/s at the start, then slow after first 5 GB (30MB/s). I noticed the SSD write speed never goes above "30MB/s" in the unraid dashboard.

Then I disabled cache for that share, did another transfer => transfer speed stays between 90MB/s-112MB/s. Unraid shows 300MB/s read, 200MB/s write for full array (this is with turbo write enabled).

Then I reanabled cache for the share, new transfer => transfer speed stays locked at 112MB/s. Unraid dashboard shows write speeds of between 100 and 150MB/s to the SSD.

I did notice that some process (SMB probably?) restarted after I switched cache off for the share, because my server was unavailable for 30 seconds or so and I had to reconnect (in windows explorer). This seems to have done something to get everything running smooth again...

Anyone any ideas what this could have been and how I can prevent this in the future?

Edited February 3, 20206 yr by ssh

Alright actually, it happened again after a few transfers. This time I screen-recorded it. https://youtu.be/v1FBsMV9weQ. Stuff starts slowing down at 2:50.

 

The CPU seems to get taxed quite much, more than I'd expect. Ofcourse, an i3 is not the quickest, but is it really bottlenecking a network transfer here?

During this transfers there were no Dockers running, no other users using the server and the transfer was transferring to the cache/SSD.
I'm running UNraid v6.8.0 at the moment, didn't install the .1/.2 update yet.

Edited February 3, 20206 yr by ssh

If like I suspected transfers are full speed to the array (with turbo write) and slow to cache, it means your cache device is the problem, make sure it's getting regularly trimmed or try a different one.

I have exactly the same issue. If I transfer between two windows machines, it keeps the speed.

2 hours ago, johnnie.black said:

If like I suspected transfers are full speed to the array (with turbo write) and slow to cache, it means your cache device is the problem, make sure it's getting regularly trimmed or try a different one.

I’ll try again tonight to directly write to the array.
 

Do I have to enable trimming for SSDs manually in unraid? I would be surprised if this would be the issue, because restarting the samba service seems to get the transfer speeds back to normal, albeit for only a little while.

6 minutes ago, ssh said:

Do I have to enable trimming for SSDs manually in unraid?

You need to install the Dynamix trim plugin and schedule it to run regularly, usually once a day is adequate.

On 2/4/2020 at 11:22 AM, johnnie.black said:

You need to install the Dynamix trim plugin and schedule it to run regularly, usually once a day is adequate.

Thanks for your suggestion, this solved the issue for me :)