Hello, I have RN104 with OS 6.9.1 on it. Since 6.9.0 i have really poor read/write performance from SMB shares. Setup: 4 drives WD RED 3TB WD30EFRX - 40% free space Link bound 2x1Gb uplinks to Netgear switch - both negotiated 1Gb (MTU 1500, static IP, no dropped frames/errors detected on switch links) AV disabled SMB3 encryption disabled globally
I have run NAStest1.7 from 3 different Windows 7 laptops - doesnt matter if connected through switch or directly to NAS - more or less same output:
It doesn't appear to be CPU bound (based on your TOP results), and a network issue seems unlikely since the direct connects are giving you the same results, and IPv6 is disabled.
Have you looked at the SMART stats for the disks (download the log zip, and look in disk_info.log)?
You could also try a balance and maybe a defrag (retesting when both complete).
Also, if ReadyCloud is installed on all the PCs, you might want to uninstall it on one, just to make sure the system isn't routing through the VPN for some reason.
Thank you for the tip - I will take a look at SMART statisticks and perform both defrag and rebalance. I will post an update when it will be finished. I'm not using ReadyCloud.
Device: sdd Controller: 0 Channel: 0 Model: WDC WD30EFRX-68EUZN0 Firmware: 80.00A80 Class: SATA RPM: 5400 Sectors: 5860533168 Pool: data PoolType: RAID 5 PoolState: 1 PoolHostId: e362f16 Health data ATA Error Count: 0 Reallocated Sectors: 0 Reallocation Events: 0 Spin Retry Count: 0 Current Pending Sector Count: 0 Uncorrectable Sector Count: 0 Temperature: 29 Start/Stop Count: 4452 Power-On Hours: 10051 Power Cycle Count: 675 Load Cycle Count: 4413
Simmilar output for the rest of drives.
I also completed defragmentation and after that rebalance process. I have re-run the test with one link in bound active. Unfortunatelly no improvement in NAStester1.7 output:
Can you try a direct-connect test, and see if that gives you better results?
You'd connect the ReadyNAS NIC directly to the PC. To do this you'd need to configure a static address on the NAS port (for instance 192.168.100.100, subnet mask 255.255.255.0, gateway 192.168.100.1), with a compatible static address on the PC (for instance, 192.168.100.101, with the same subnet mask and gateway). Then run NAStester using the ReadyNAS static address.
I have tried that. No change. Still the same poor performance...
I'm not sure what could I check more. It's definitely something wrong with NAS, but I do not get any errors in logs. As I mentioned this started after 6.9.0 upgrade, however downgrade to version prior 6.9.0 is not recommended by vendor.
It is also pretty simple to install iperf on the NAS and the windows system, and measure the network throughput (separately from the disk performance).
Note also that 6.9.2 is released - though I don't know of any reason that would resolve your issue, it is something you could try.
root@NAS:/# dd if=/dev/zero of=/data/test1.img bs=200M count=1 oflag=dsync 1+0 records in 1+0 records out 209715200 bytes (210 MB, 200 MiB) copied, 5.75487 s, 36.4 MB/s
root@NAS:/# dd if=/dev/zero of=/data/test2.img bs=512 count=500 oflag=dsync 500+0 records in 500+0 records out 256000 bytes (256 kB, 250 KiB) copied, 40.377 s, 6.3 kB/s
However one strange thing when I have change te file size to 400M:
root@NAS:/# dd if=/dev/zero of=/data/test1.img bs=400M count=1 oflag=dsync 1+0 records in 1+0 records out 419430400 bytes (419 MB, 400 MiB) copied, 114.464 s, 3.7MB/s
This is the value more or less the same I'm getting during file write to SMB. However I'm not sure if this is related. While idle I have about half memory free so about 256MB. File 200MB fits the memory, file 400MB does not. When I run the top during this dd process in second session I can see that NAS is swapping memory:
root@NAS:/# dd if=/dev/zero of=/data/test1.img bs=200M count=1 oflag=dsync 1+0 records in 1+0 records out 209715200 bytes (210 MB, 200 MiB) copied, 5.75487 s, 36.4 MB/s
However one strange thing when I have change te file size to 400M:
root@NAS:/# dd if=/dev/zero of=/data/test1.img bs=400M count=1 oflag=dsync 1+0 records in 1+0 records out 419430400 bytes (419 MB, 400 MiB) copied, 114.464 s, 3.7MB/s
This is the value more or less the same I'm getting during file write to SMB. However I'm not sure if this is related. While idle I have about half memory free so about 256MB. File 200MB fits the memory, file 400MB does not. When I run the top during this dd process in second session I can see that NAS is swapping memory:
It does make me wonder if the NAS is starved for memory though. Does NAStester give a faster result with 200 MB/sec?
What file sharing protocols are enabled? In particular, if NFS is enabled, try disabling it (or reducing the number of user threads to 4).
Well, it doesn't seem to be the network (since the iperf tests were fine), and the internal disk speed seemed fine as long as you didn't trigger the swapping.
Do you have any scratch disks? If you do, you could try powering down and removing the current disks (labeling by slot) and then do a factory install with only the scratch installed. Then test the speeds with a fresh install.
Of course, something can always go wrong. But OS reinstalls are designed to be non-destructive, and generally are quite safe. They will reset the IP configuration to DHCP (likely it already is), reset the admin password to password, and disable quotas on the data volume.
So you'd need to reset the admin password for sure. Disabling quotas might actually improve the performance, so you might check to see if they are enabled now (look in the settings wheel on the volume tab).
Apart from the quota possibility, the OS-reinstall seems unlikely to improve performance. If your data volume is very old, then a factory reset likely will improve it.
It's early days with 6.9.3-beta, but it's safe mode will provide another way to get at the data when a firmware install or OS reinstall goes bad. Of course, installing beta releases has it's own risks.
I created a new folder with the same settings. After the test I'm getting ~30MB/s - so it's good.
I copied almost all the files from old folder to the new one and it was still ok. When I copied the biggest archive file which is currently ~1,5TB in size the performance for this folder dropped to ~3MB/s. In other words it looks like the presence of big file (even if the file is not used by anyone during the test) kills the NAS performance on folder level. Strange thing is that prior the 6.9.0 upgrade there were no issues with that.
Now I know what is the reason of this performance drop but I do not know if anything can be done with this, as removal of this file is not an option.
