From: Wilson, S. M <st...@pu...> - 2016-11-02 19:31:40
|
Hi, We have several workstations that are using the latest version of mfsmount (3.0.84) and I've started to receive complaints about very slow performance. I ran a few tests (untarring the Linux kernel source) and it appears that on the 3.0.84 clients performance will continue to degrade each time I run the test. For example, one workstation shows these results from three successive runs: ? root@saturn:/net/em/test# time tar xf linux-4.9-rc3.tar; time rm -rf linux-4.9-rc3 real 4m34.614s user 0m1.416s sys 0m7.480s real 2m57.863s user 0m0.436s sys 0m2.192s root@saturn:/net/em/test# time tar xf linux-4.9-rc3.tar; time rm -rf linux-4.9-rc3 real 6m59.159s user 0m1.924s sys 0m7.276s real 5m39.582s user 0m0.484s sys 0m2.548s root@saturn:/net/em/test# time tar xf linux-4.9-rc3.tar; time rm -rf linux-4.9-rc3 real 9m1.816s user 0m1.928s sys 0m7.160s real 7m54.979s user 0m0.584s sys 0m2.968s ? ?If I unmount the file system and then mount it again, performance returns to normal but will degrade over time like before. On the other hand, if I run the same test on a different client using mfsmount 3.0.81 then my performance remains stable and doesn't degrade over time after heavy use. Is there perhaps a problem with mfsmount versions higher than 3.0.81? I should add that none of my servers (master, metalogger, chunk) are running higher than 3.0.81 so this could be due to a mismatch between mfsmount and server version. I doubt this but I wanted to mention it. Just to mention in passing, the same test on a local disk is blazingly fast in comparison. I understand that this is a really tortuous test for a distributed file system but the performance discrepancy is quite substantial (5 seconds vs. 275 seconds for the untar, 1 second vs. 178 seconds for the rm). Here are the timings on the local disk:? stevew@otter:/otter-scratch/TEST$ time tar xf linux-4.9-rc3.tar; time rm -rf linux-4.9-rc3 real 0m5.419s user 0m0.304s sys 0m2.368s real 0m1.038s user 0m0.052s sys 0m0.976s ? Thanks, Steve |