Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47429

Absolutely atrocious user lookup performance when many legacy users

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • core 2.60.x, Git plugin, and user viewing changesets when a lot of users exist.

      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.

          [JENKINS-47429] Absolutely atrocious user lookup performance when many legacy users

          James Dumay added a comment -

          jglick is there some assistance from vivek that could be provided to help get this over the line? (I see you've opened a PR but this one isn't assigned to you - assuming that PR isn't the whole story?)

          James Dumay added a comment - jglick is there some assistance from vivek that could be provided to help get this over the line? (I see you've opened a PR but this one isn't assigned to you - assuming that PR isn't the whole story?)

          Vivek Pandey added a comment - - edited

          As far as blueocean is concerned URL: https://ci.blueocean.io/blue/organizations/jenkins/blueocean/detail/BRANCH/RUN_ID/changes/ gets called only when Changes Tab on run details page gets clicked by user. Not in critical path, although for large change set it might makes page load slow. Eventually when it gets fixed in core or upstream library we are going to see it working optimally. Nothing to do for now in blueocean.

          Vivek Pandey added a comment - - edited As far as blueocean is concerned URL: https://ci.blueocean.io/blue/organizations/jenkins/blueocean/detail/BRANCH/RUN_ID/changes/ gets called only when Changes Tab on run details page gets clicked by user. Not in critical path, although for large change set it might makes page load slow. Eventually when it gets fixed in core or upstream library we are going to see it working optimally. Nothing to do for now in blueocean.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/hudson/model/User.java
          http://jenkins-ci.org/commit/jenkins/3853b3813967bd3d46e4dde7741eb97fa628345c
          Log:
          JENKINS-47429 User.getLegacyConfigFilesFor no longer seems to be necessary.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/model/User.java http://jenkins-ci.org/commit/jenkins/3853b3813967bd3d46e4dde7741eb97fa628345c Log: JENKINS-47429 User.getLegacyConfigFilesFor no longer seems to be necessary.

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/hudson/model/User.java
          http://jenkins-ci.org/commit/jenkins/53a320afd86844ad82c2d7fa7b64e4143e776c55
          Log:
          Merge pull request #3150 from jglick/User-JENKINS-47429

          JENKINS-47429 User.getLegacyConfigFilesFor no longer seems to be necessary

          Compare: https://github.com/jenkinsci/jenkins/compare/5f8f42624eb5...53a320afd868

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/hudson/model/User.java http://jenkins-ci.org/commit/jenkins/53a320afd86844ad82c2d7fa7b64e4143e776c55 Log: Merge pull request #3150 from jglick/User- JENKINS-47429 JENKINS-47429 User.getLegacyConfigFilesFor no longer seems to be necessary Compare: https://github.com/jenkinsci/jenkins/compare/5f8f42624eb5...53a320afd868

          Oleg Nenashev added a comment -

          The fix has been integrated towards 2.93

          Oleg Nenashev added a comment - The fix has been integrated towards 2.93

          James Dumay added a comment -

          James Dumay added a comment - oleg_nenashev jglick nice one

          Oleg Nenashev added a comment -

          Marked the fix as the lts-canididate, but I am not 100% sure it is safe. jglick WDYT?

          Oleg Nenashev added a comment - Marked the fix as the lts-canididate, but I am not 100% sure it is safe. jglick WDYT?

          Arnaud Héritier added a comment - oleg_nenashev , danielbeck , jglick , olivergondza https://jenkins.io/changelog-stable/  doesn't list  JENKINS-47429 as fixed in 2.89.2 ? But it seems to be here : https://github.com/jenkinsci/jenkins/commit/b450e9bdb60f6b3a0d492219a026438bf7b3b9d6 JENKINS-48157 , JENKINS-34138 are also missing ?

          Oleg Nenashev added a comment -

          2.89.2 was an out-of-order Security release. The changes listed in 2.89.2-fixed will be actually released in 2.89.3 IIUC, but somebody told me the different thing a while ago. Probably it was you

          Oleg Nenashev added a comment - 2.89.2 was an out-of-order Security release. The changes listed in 2.89.2-fixed will be actually released in 2.89.3 IIUC, but somebody told me the different thing a while ago. Probably it was you

          Daniel Beck added a comment -

          Daniel Beck added a comment - https://groups.google.com/d/msg/jenkinsci-dev/YNCLWs7cBHc/FKrH97ZoCwAJ

            jglick Jesse Glick
            svanoort Sam Van Oort
            Votes:
            2 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: