The performance of user lookup when many users with legacy config files exist has been identified as the cause of a master's CPU usage spiking to the point of unresponsiveness. 

Stack trace:

at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.isFile(File.java:882)
at hudson.model.User$3.accept(User.java:697)
at java.io.File.listFiles(File.java:1291)
at hudson.model.User.getLegacyConfigFilesFor(User.java:694)
at hudson.model.User.getOrCreate(User.java:437)
at hudson.model.User.getById(User.java:535)
at hudson.model.User$UserIDCanonicalIdResolver.resolveCanonicalId(User.java:1086)
at hudson.model.User.get(User.java:405)
at hudson.model.User.get(User.java:374)
at hudson.plugins.git.GitChangeSet.findOrCreateUser(GitChangeSet.java:379)
at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:448)

The root cause of the problem is that for every user we're doing an O(n) scan through the directories in that folder looking for legacy user config files:

 private static final File[] getLegacyConfigFilesFor(final String id) {
        return getRootDir().listFiles(new FileFilter() {
            @Override
            public boolean accept(File pathname) {
                return pathname.isDirectory() && new File(pathname, "config.xml").isFile() && idStrategy().equals(
                        pathname.getName(), id);
            }
        });
    }

Code here: https://github.com/jenkinsci/jenkins/blob/2d2101215dc39dfcb03279e3cb8898b8b9e5bc5f/core/src/main/java/hudson/model/User.java#L680

The likely best fix is either to be able to check for a single file (if case sensitive mode is on) or to cache the list of entries in that folder so we don't need to do a listFiles and linear-time scan through all entries with a FileFilter.