NFS shared folder with linux extremely slow

[cool.codecoding]

Hey everyone,

i just set up a NFS shared folder on my ds218+ (2x8tb ironwolf, RAID 1) to use with my ubuntu 20 workstation. I can read and write files in the mounted folder. Unfortunately i cannot exceed 7mb/s when writing data to the NAS. My worktation has a SSD.
I checked the following:
[QUOTE] dd if=/dev/zero of=/home/noah/nas_data/testfile bs=16k [/QUOTE] [QUOTE] 135640285184 bytes (136 GB, 126 GiB) copied, 271,284 s, 500 MB/s [/QUOTE]
If my understanding is correct, i achieve high performance when copying big files. However, when transfering e.g. photos the transfer speed does not exceed 7mb/s. I already checked out this link from synology website and searched for a couple of hours for a solutions:
synology website post

Is there a configuration problem on my DS or the way i mounted the shared folder on my workstation? How could I find the bottleneck and achieve higher transfer speed even with multiple smaller files?

I'm happy for all hints and tips as well as code snippets, as I am quite new to this topic.


EDIT: I just did a iperf3 test and got around 900 mbits/s with cable and 80 mbits/s with wifi. So I guess its the wifi connection, that makes it so slow.
any ideas how to improve it?

 

[jeyare]

insufficiently described

1. one of the problem is your defined parameter of block sizes in dd command. This size (16k bytes) could be source of transferred packets fragmentation = slow speed.
Properly chosen block size is defined by your E2E architecture (from each points of client side, LAN, NAS side). Doesn't mater if you have super fast SSDs (no one know what exactly kind of NAND technology there, ...).

2. there is another point of view. Used "dd" command has also extended definition of ibs & obs parameters:
- ibs = input block size
- obs = output block size
used bs parameter is for same size of ibs and obs ...... what could be tricky and another reason of your low performance

You need more tests, then an evaluation. No one can give you a "gold" formula. No one knows your E2E architecture setup.

this old blog was saved by me to my favorites "speed tune" bookmarks 5y ago. Still one of the valid approaches:

Tuning dd block size

Though I wouldn't call myself a dd expert, I have had my fair share of occasions to yield the might that is dd. From my first job after college using KNOPPIX and dd to rescue NFL game footage from dying HDDs on behalf of NFL video coordinators, to using dd...

blog.tdg5.com

3. rater than "dd" command is better to use "rsync" for better speed
there is another reason - a preservation of the properties (ownership, timestamp, ...)

 

[WST16]

Big difference between the wired and the wireless connection.
You might need to check if both, the WiFi router/access point and your PC WiFi are on the 5GHz band (not the slower 2.4GHz).

 

[jeyare]

EDIT: I just did a iperf3 test and got around 900 mbits/s with cable and 80 mbits/s with wifi. So I guess its the wifi connection, that makes it so slow.
any ideas how to improve it?

So the verdict is still just a shoot into dark for everyone without knowledge about your LAN topology setup.

What was exactly the used iperf command?

Finally you can't mix apples & pears results:
- as was written by @WST16 (two different transfer medium wire and air) = all possible setup to performance influencing in WiFi only part

- testing results of single file from the iperf (if any, instead of frequently using random data) ... there are various protocols, + setup of the blocks .... just to be sure, the iperf server is hosted in your NAS or it was tested one of the available iperf WAN servers?

- testing results of data from dd commands description

You have to evaluate same LAN environment precisely with same testing data samples (never with single file only).
Otherwise you will compare two different cars with two different performance setup and two different load in the each car, fueled with two different mediums (petrol, diesel). Then you can compare just color of the cars.