On Thursday, 12 October 2023 21:50:28 BST Dale wrote: > Neil Bothwick wrote: > > On Thu, 12 Oct 2023 07:36:17 -0500, Dale wrote: > >> Neil Bothwick wrote: > >>> On Wed, 11 Oct 2023 17:52:58 -0500, Dale wrote: > >>>> It only does this when I'm copying files over. Right now I'm copying > >>>> about 26TBs of data over ethernet and it is taking a while. Once I > >>>> stop it or it finishes the copy, the CPU goes to about nothing, > >>>> unless I'm doing something else. So it has something to do with the > >>>> copy process. > >>> > >>> Or the network. What are you using to copy? If you use rsync, you can > >>> make use the the --bwlimit option to reduce the speed and network > >>> load. > >> > >> Reduce? I wouldn't complain if it went faster. I think it is about as > >> fast as it is going to get tho. > > > > And that may be contributing to the CPU usage. Slowing down the flow may > > make the comouter more usable, and you're never going to copy 26TB > > quickly, especially over ethernet. > > > >> While I'm not sure what is keeping me from copying as fast as the drives > >> themselves can go, I suspect it is the encryption.
Why don't you test throughput without encryption to confirm your assumption? > > If you're copying over the network, that will be the limiting factor. > > Someone posted some extra options to mount with and add to exports > file. Those added options almost doubled the speed. I watch gkrellm > and I think it is going about as fast as it can. My problem is, some > software uses one unit to measure things while another uses something > else. It makes it hard to figure out what is doing what. Still, using > gkrellm which is something I'm used to watching when it comes to drive > read/write data, I think it is as good as it is going to get. Not that > I'm not open to trying other options that might speed things up. I > still think encryption is slowing it down some. As you say tho, > ethernet isn't helping which is why I may look into other options later, > faster ethernet or fiber if I can find something cheap enough. There are a lot of hypotheses in your statements, but not much testing to prove or disprove any of them. Why don't you try to isolate the cause by testing one system element at a time and see what results you get. Copy a large file from tmpfs to tmpfs to see how fast it can transfer across your LAN - or use iperf3 as already recommended. Use a file size large enough to saturate your network and give you a real life max throughput. Repeat, but this time copy the large file over to disk. Repeat, but this time try different filesystems, disks, volumes, strides/ stripes, add encryption, compression, whatnot. You may spend an hour or two, but you'd soon isolate the major contributing factor(s) causing the observed slowdown. Unless you're running Pentium 4 or some other old CPU, it is almost certain your CPU is capable of using AES-NI to offload to hardware some/all of the encryption/decryption load - as long as you have the crypto module built in your kernel. PS. Keep notes and flush caches between tests to avoid drawing conclusions on spurious results.
signature.asc
Description: This is a digitally signed message part.
