On Sat, Jan 7, 2017 at 9:31 AM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote:
> Hi, > > I have used hg (mercurial) satisfactorily until about a month ago or so. > Somehow hg diff has become very slow. > I am using it on two Debian GNU/Linux PC (64-bit). > It is possible that latest OK kernel update in Debian may have changed > something like file cache policy, etc. But user visible change like this is > rather unlikely. > > I am using fsmonitor extension, and maybe there could have been changes > related inotify in the recent kernels offered by Debian. > My version is linux 4.7.0-1 > uname -a > Linux ip030 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64 > GNU/Linux > > (Come to think of it, I should get a newer fsmonitor from facebook site > for 4.7.0-1 or later kernel.) > > Or maybe the change in the kernel might have caused the changes in the > optimal setting for > sysctl fs.inotify.max_user_watches= ??? > sysctl fs.inotify.max_queued_events= ??? > sysctl fs.inotify.max_user_instances= ??? > > Has anyone experienced such strange slowdown recently under Debian > GNU/linux with 4.7.x kernel? > Or can someone suggest a modern optimal set of values of s.inotify.max* ? > Running any `hg` command with `--profile` will invoke a Python profiler and print what's taking so long. I can help you decode that. Keep in mind that if a pager is configured, time spent waiting for pager to exit will skew results. So you can disable pager by redirecting stdout to /dev/null or setting `--pager=false` Alternatively, setting HGRCPATH to an empty value will disable loading of your global config file, disabling extensions (like pager) and isolating behavior of vanilla Mercurial, which can help isolate performance issues as caused by extensions. In this case, fsmonitor *should* make things faster, so you could do something like `HGRCPATH= hg --config extensions.fsmonitor=` to disable everything then load fsmonitor explicitly. It's not unheard of for fsmonitor to slow things down in some scenarios. This can happen on first run or if inotify is hitting limits. I use the following limits without any major problems: fs.inotify.max_queued_events = 65536 fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 512000
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
