https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-338 Instrument control development <p>The VMs seem to be very slow, probably from IO.<br/> I'll compare installing conda on shell-ics to an NFS-mounted /software, to installing on a physical oldish machine with not special spinning disks. I'd expect the NFS to maybe cause some slowdown, but I though there was a fast cache for that on the server? But it is much worse than that – bad enough to be a problem.</p> <p><tt>bash Miniconda3-latest-Linux-x86_64.sh -b -p /software/conda</tt>: 2m22 vs. 13s<br/> <tt>conda update -y conda</tt>: 1m5s vs. 16s<br/> <tt>conda install numpy cython twisted ply future astropy ruamel_yaml ipython</tt>: 6m48s vs. 2m42s</p> INSTRM-338

Improve performance on PFS machines at Subaru

Task Normal Open Unresolved Unassigned cloomis Wed, 25 Apr 2018 19:53:28 +0000 Thu, 10 May 2018 08:25:48 +0000 Wed, 25 Apr 2018 19:53:28 +0000 ics_production 0 3 <p>it is known/reported/discussed issue which I have not succeeded to resolve more than two/three years, that jfs+nfs has significant (~2 times) performance issue on appending to files more than 1-2TB, and xfs+jfs has significant (~1 digit / ~10 times) performance issue on any stat action to dir/file. so, for now PFS servers at IPMU uses jfs for its NFS server, but following Princeton order I configured the summit as xfs for NFS storage.<br/> so, help wanted, or wontfix.</p> <p>The disk controller has a battery-backed RAM cache, right? Are the xfs barriers turned off (along with disk caches)?</p> <p>its due to a combination of xfs and NFS, so it does not depends on its storage device. ~1 digit performance degradation was measured between physical and NFS, as previously reported.</p> <p>But XFS barriers do matter, especially on NFS servers – if you can legitimately turn them off because you have battery-backed cache in the right place, you gain <em>enormously</em>.</p> <p>if it is an issue on bulk (or even sequential) read/write performance, such async or caching could work well, but the issue is handling of stat. <br/> async option could help a bit for stat performance, but it is after NFS server-client communication (like server reply immediately after commit with no-op) and in filesystem + block device, so it would not have any significant change for our issue.</p> <ol> <li>actually, testing with noatime (client), async (server) does not change stat performance.</li> </ol> Development Rank 0|ii04db: