NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RN214 - Extremely slow with zip files
Hi, I have a ReadyNAS 214 and it used to be fine before but since about 6-8 months or so, it is extremely painfully slow to compress / decompress zip files. Is it normal? Why would it be so slow? Any...
It's not something I do much. My setup is different (a 526x NAS using a 10gbit network - and no encryption). If I have a chance, I'll try to duplicate your results on a Windows PC and see how that compares. I use 7-zip (not sure if that will make a difference or not).
StephenB wrote:
I'll try to duplicate your results on a Windows PC and see how that compares. I use 7-zip (not sure if that will make a difference or not).
Turns out the 7-zip command line interface is a bit restrictive - it won't allow me to put an output zip on the SSD when the source is on the NAS.
However, I was able to compare SSD->SSD performance on my PC with NAS->NAS performance using a mapped drive on the PC. While the NAS->NAS performance was slower, it wasn't anything like what you are seeing. My test folder has 5884 files in 177 folders, and a total size of about 500 MB.
I suggest trying your test w/o the round-robin bonding - just to see if that is a factor. You could also try to duplicate my results with 7za.
Local SSD->Local SSD Zip Creation took about 12 seconds (Global Time is the actual wall clock time).
Test1: Create Zip SSD->SSD 7za a -bt -tzip LocalTestSrc Files read from disk: 5884 Archive size: 297220124 bytes (284 MiB) Everything is Ok Kernel Time = 1.968 = 16% 132515 MCycles User Time = 38.171 = 325% Process Time = 40.140 = 342% Virtual Memory = 150 MB Global Time = 11.722 = 100% Physical Memory = 90 MB
NAS->NAS Zip creation took about 40 seconds - definitely longer, but not minute/hours.
Test2: Create Zip NAS->NAS (526x mapped drive) 7za a -bt -tzip NASTestSrc Files read from disk: 5884 Archive size: 297195876 bytes (284 MiB) Everything is Ok Kernel Time = 4.593 = 11% 146766 MCycles User Time = 39.234 = 99% Process Time = 43.828 = 111% Virtual Memory = 150 MB Global Time = 39.332 = 100% Physical Memory = 48 MB
FWIW, the process time and cycle count is really quite close. I'm guessing the difference is SMB latency.
Local SSD-SSD extraction also took about 12 seconds:
Test3: Extract ZIP SSD->SSD 7za x -bt -tzip LocalTestSrc.zip Folders: 178 Files: 5884 Size: 486495926 Compressed: 297220124 Kernel Time = 6.875 = 58% 35717 MCycles User Time = 3.843 = 32% Process Time = 10.718 = 91% Virtual Memory = 5 MB Global Time = 11.736 = 100% Physical Memory = 9 MB
NAS->NAS extraction took about 80 seconds
Test4: Extract ZIP NAS->NAS (526x mapped drive) 7za x -bt -tzip NASTestSrc.zip Folders: 178 Files: 5884 Size: 486495926 Compressed: 297195876 Kernel Time = 14.796 = 18% 62914 MCycles User Time = 3.453 = 4% Process Time = 18.250 = 23% Virtual Memory = 5 MB Global Time = 78.821 = 100% Physical Memory = 9 MB
Process time and cycle counts are higher than the local extraction test, but I think the main difference is again SMB latency.
I then repeated the NAS->NAS tests on an RN202. I'm not using bonding (and I don't use volume encryption). The share is on a jbod volume.
The NAS->NAS zip creation results were similar to the RN526 performance. The extraction test was quite a bit worse (165 seconds, compared with 79). Still not minutes/hours though.
Total guess, but try disabling strict sync on the share. That causes Veracrypt to slow to a crawl on writes, and this may be related. If you are running SMB Plus and have enabled pre-allocation, you should also try disabling that.
Sandshark wrote:
Total guess, but try disabling strict sync on the share. That causes Veracrypt to slow to a crawl on writes, and this may be related. If you are running SMB Plus and have enabled pre-allocation, you should also try disabling that.
Strict sync was enabled in my measurements, so that isn't it.
I don't see how pre-allocation would affect extraction to the local PC hard drive, since the NAS is only being read.
Could the zip file (or the share) be heavily fragmented?
How full is the volume?
StephenB: I use 7zip too. Whatever you use will have a slight difference but that doesn't make much of a difference.
No 7zip in command line is not restrictive, I can output or zip with a command from and to a NAS, I've done it plenty of times on different computers, no idea what problem you're having but it should work.
You suggested that I disabled the bond so I did. I also removed one ethernet cable, so now I only have one ethernet cable plugged and here is the result with a 312.8 MB zipped file with 766 folders and 5517 files inside:
Laptop - Windows - From mechanical HD to mechanical HD = 16s
RN214 - SSH - From NAS to NAS =14.6s
Desktop - Linux - Wired - GUI - From NAS to NAS = 2m
Desktop - Linux - Wired - Terminal - From NAS to NAS =1m 54s
Laptop - Windows - Wireless - From NAS to NAS = 10m 14s
Ouch, that last one of 10m is quite something!
In my first test, if you compare the SSH extraction (56 seconds) to "Linux - Terminal" (48 minutes), the latter was 5143% slower.
In this test, the difference is 781% slower, that is much better than before! Looks like the bond0 I had wasn't good. It is true that I just plugged both cables in my router without any special configuration. However, it is still slow and still extremely slow in wireless (4206% slower), I'm having trouble wondering why that would be, why the network would make such a huge difference.
Sandshark: You suggested disabling "strict sync" which is in Share / Settings / Network Access / SMB / Advanced and here's the new results with the same file (I didn't rebooted the NAS, hopefully it doesn't matter):
Laptop - Windows - From mechanical HD to mechanical HD = 16s
RN214 - SSH - From NAS to NAS =14.6s
Desktop - Linux - Wired - GUI - From NAS to NAS = 2m
Desktop - Linux - Wired - Terminal - From NAS to NAS = 1m 54s
Laptop - Windows - Wireless - From NAS to NAS = 10m 11s
In this test, the strict sync did absolutely nothing unfortunately.
What is strist sync?
https://www.samba.org/samba/docs/using_samba/ch11.html
This share-level option determines whether Samba honors all requests to perform a disk sync when requested to do so by a client. Many Windows clients request a disk sync when they are really just trying to flush data to their own open files. In this case, a disk sync is generally unnecessary on Unix due to its high reliability, and it mostly has the effect of substantially reducing the performance of the Samba host system. The default value for this option is no, which allows the superfluous disk sync requests to be ignored.
Because of this, I think it's a good thing to not have it enabled. If you install Samba, it is not enabled by default. I wonder why Netgear would turn it on by default.
StephenB: About fragementation, there is an option in Volumes / Settings to Defrag. I will try it, it will take time so new results will be posted later.
About the free space, I have one share in RAID 5, 4.19 TB of data and 6.70 TB of free space total of 10.90 TB so I have enough free space.
So it is faster right now but I still think something is wrong, it should be faster. In your test of extraction (which are different tests that I did) from SSD to SSD (12s) compared to NAS to NAS (80 seconds), it is 667% slower, huge difference.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
