RN104 - Really Slow Copy Speeds

This is interesting. I have heard about this type of behaviour before.

I wonder if the NAS struggles with memory when copying like this.

Try to rsync it instead, from the CLI. Is performance better then?

Also, what does a dd test reveal?

cd into one of your shares and then dd a file.
# dd if=/dev/zero of=bigfile.bin bs=4M count=250

Here is an example from my RN422. It is of course faster than your NAS, but for the purpose of demonstration...

root@Datastore:/data/Public# dd if=/dev/zero of=bigfile.bin bs=4M count=250
250+0 records in
250+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 5.20838 s, 201 MB/s

It's still handling that other backup job, so I haven't run any benchmarks on it.

Looking at 'top' I've got

readynasd taking up 20-25% of the cpu

smbd taking up 25-28% (I'm copying a file through windows, only between 12-18mb/s right now)

kswapd0 taking up 12-14%

fvbackup taking 12-14% (still that one share backup, probably somewhere between 6 to 10mb/s)

Of 508732 total KiB of Mem, there's around 1800-25000 free. 

minidlnad is using about 70% of the memory, but not much cpu.

---

WiredRacing wrote:

 

minidlnad is using about 70% of the memory, but not much cpu.

---

You could try disabling the DLNA service and see if that makes any difference.

The 'minidlnad' processed eventually dropped off 'top' and went down to sub 6%. Though curiously the amount of memory in use stayed the same.

When my SMB copy stopped, I stopped readynasd (as it was always trying to take up 100% of the cpu) and then started it and it started to behave "normally" (only spiking when using the management console). However, I tried another copy within midnight commander, large file, and it still didn't go over 10mb/s while the SMB copy with readynasd under control and no other backup process happening would top out in the mid 50's (generally hanging around in the mid 40's). smbd around migh 50 to mid 60% cpu, which kicks up kswapd0 to low teens. 3 kworker processes, usually 2 of them equal 10%. 

When I sort 'top' by mem%, 'minidlnad' it's the highest (at 5.6%) but no other process seems to be using a lot of memory despite 480000 used and only ~30000 free. The swap looks much better now though, only 10,416 used. 3-5 running tasks, 187(!) sleeping (0 stopped or zombie).

So yeah this is still quite odd why smb copies so much faster. Haven't rebooted yet, ALMOST done migrating all my data over. Just a few more hours now. 

So, after powering down. Moving my new drive that I was copying all this data to into another slot, turning it back on. Then shutting down again and reinstalling an exported 2-disk volume, turning it back on to verify it worked. Then exporting it again, removing it. Putting two other disks in, creating a RAID 0 volume of those and manually editing smb.conf (which was not loading due to "smb encryption = (null)"). I created some backup jobs to backup data from the Bay 1 drive to this new array and I'mgetting an avg of 44mb/s through the management console and using the backup jobs. 

So it appears, somewhere in that process, part of my problem(s) corrected themselves.

Once the backups are done, I'll run the various commands and tests mentioned here and post the results for future reference.

Going to probably need to start another thread on the SMB config issue because as soon as I reboot, it will overwrite my change, so somewhere else in the system is some thing else that needs to change, or I need help to write a script to update and re-try 'systemctl start smb' after a minute or two after booting. Anyhow, separate issue (but part of the odyssey of this single drive upgrade project).