Details

    • Improvement
    • Resolution: Unresolved
    • Minor
    • None
    • None
    • VMs + 2.12.8 + 3.10.0-1160.59.1
      robinhood v3 + 2.12.8 + 3.10.0-1062
    • 9223372036854775807

    Description

      This issue was observed with robinhood clients:

      • robinhood become slower to sync the fs with changelog with the time
      • robinhood become slower if the reader is late (more negative entries generated).

      "strace" on reader threads reveal that the FID stats could take several seconds.
      drop_cache 2 or 3 fixes temporary the issue.

      Reproducer
      I was able to reproduce the issue with a "dumb" executable that generate a lot of "negative entries" with parallel stats on "<fs>/.lustre/fid/<non_existent_fid>".
      The perf_fid_cont.svg is a flamegraph on the threads of the test process (fid_rand).

      Most of the threads of fid_rand wait for the mutex of "./lustre/fid" inode in:

      static int lookup_slow(struct nameidata *nd, struct path *path)
      {                                                              
              struct dentry *dentry, *parent;                        
              int err;                                               
                                                                     
              parent = nd->path.dentry;                              
              BUG_ON(nd->inode != parent->d_inode);                  
                                                                     
              mutex_lock(&parent->d_inode->i_mutex);                            <--- contention here
              dentry = __lookup_hash(&nd->last, parent, nd->flags);  
              mutex_unlock(&parent->d_inode->i_mutex); 
      

      workarround

      • crontab with "echo 2 > /proc/sys/vm/drop_caches"
      • set the "/proc/sys/fs/negative-dentry-limit" on 3.10.0-1160 kernel

      Attachments

        Activity

          [LU-16047] cache contention in ".lustre/fid/
          eaujames Etienne Aujames made changes -
          Labels Original: performance New: performance robinhood
          eaujames Etienne Aujames made changes -
          Labels New: performance
          pjones Peter Jones made changes -
          Assignee Original: WC Triage [ wc-triage ] New: Etienne Aujames [ eaujames ]
          eaujames Etienne Aujames made changes -
          Description Original: This issue was observed with robinhood clients:
          * robinhood become slower to sync the fs with changelog with the time
          * robinhood become slower to sync the fs with changelog if the reader is late (more negative entries generated).

          "strace" on reader threads reveal that stat could take several seconds.
          drop_cache 2 or 3 fixes temporary the issue.

          The [^perf_fid_cont.svg] is flamegraph
          New: This issue was observed with robinhood clients:
          * robinhood become slower to sync the fs with changelog with the time
          * robinhood become slower if the reader is late (more negative entries generated).

          "strace" on reader threads reveal that the FID stats could take several seconds.
          drop_cache 2 or 3 fixes temporary the issue.

          *Reproducer*
          I was able to reproduce the issue with a "dumb" executable that generate a lot of "negative entries" with parallel stats on "<fs>/.lustre/fid/<non_existent_fid>".
          The [^perf_fid_cont.svg] is a flamegraph on the threads of the test process (fid_rand).

          Most of the threads of fid_rand wait for the mutex of "./lustre/fid" inode in:
          {code:c}
          static int lookup_slow(struct nameidata *nd, struct path *path)
          {
                  struct dentry *dentry, *parent;
                  int err;
                                                                         
                  parent = nd->path.dentry;
                  BUG_ON(nd->inode != parent->d_inode);
                                                                         
                  mutex_lock(&parent->d_inode->i_mutex); <--- contention here
                  dentry = __lookup_hash(&nd->last, parent, nd->flags);
                  mutex_unlock(&parent->d_inode->i_mutex);
          {code}

          *workarround*
          * crontab with "echo 2 > /proc/sys/vm/drop_caches"
          * set the "/proc/sys/fs/negative-dentry-limit" on 3.10.0-1160 kernel
          eaujames Etienne Aujames made changes -
          Description Original: This issue was observed with robinhood clients:
          * robinhood become slower to sync the fs with changelog with the time
          * robinhood become slower to sync the fs with changelog if the reader is late (more negative entries generated).

          "strace" on reader threads reveal that stat could take several seconds.
          drop_cache 2 or 3 fixes temporary the issue.
          New: This issue was observed with robinhood clients:
          * robinhood become slower to sync the fs with changelog with the time
          * robinhood become slower to sync the fs with changelog if the reader is late (more negative entries generated).

          "strace" on reader threads reveal that stat could take several seconds.
          drop_cache 2 or 3 fixes temporary the issue.

          The [^perf_fid_cont.svg] is flamegraph
          eaujames Etienne Aujames made changes -
          Attachment New: perf_fid_cont.svg [ 44815 ]
          eaujames Etienne Aujames created issue -

          People

            eaujames Etienne Aujames
            eaujames Etienne Aujames
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated: