Solr
  1. Solr
  2. SOLR-207

snappuller inefficient finding latest snapshot

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2
    • Component/s: replication (scripts)
    • Labels:
      None

      Description

      snapinstaller (and snappuller) do the following to find the latest snapshot:
      name=`find $

      {data_dir}

      -name snapshot.* -print|grep -v wip|sort -r|head -1`

      This recurses into all of the snapshot directories, doing much more disk-io than is necessary.
      I think it is the cause of bloated kernel memory usage we have seen on some of our Linux boxes, caused
      by kernel dentry and inode caches. Those caches compete with buffer cache (caching the actual data of the index)
      and can thus decrease performance.

      1. find_maxdepth.patch
        3 kB
        Yonik Seeley
      2. find_maxdepth.patch
        2 kB
        Yonik Seeley

        Activity

        Hide
        Yonik Seeley added a comment -

        uses "-maxdepth 1" to avoid recursion.

        Bill - does this look OK?

        Show
        Yonik Seeley added a comment - uses "-maxdepth 1" to avoid recursion. Bill - does this look OK?
        Hide
        Bertrand Delacretaz added a comment -

        IIUC the snapshot directories are named like

        snapshot.YYYYMMDDHHMMSS

        and they are all under the same parent directory.

        If that's the case, then doing

        ls -rt $

        {data_dir}

        /snapshot.* | head -1

        will return the name of the most recent directory, efficiently.

        Show
        Bertrand Delacretaz added a comment - IIUC the snapshot directories are named like snapshot.YYYYMMDDHHMMSS and they are all under the same parent directory. If that's the case, then doing ls -rt $ {data_dir} /snapshot.* | head -1 will return the name of the most recent directory, efficiently.
        Hide
        Yonik Seeley added a comment -

        That's close to the way it was done in the past, but some people ran into problems because of shell restrictions w.r.t. number or size of the argments passed to the process (because the shell expands the list).

        Show
        Yonik Seeley added a comment - That's close to the way it was done in the past, but some people ran into problems because of shell restrictions w.r.t. number or size of the argments passed to the process (because the shell expands the list).
        Hide
        Yonik Seeley added a comment -

        Although, another alternative that doesn't have the shell expansion problem would be

        ls -r $

        {data_dir}

        | grep snapshot
        . | grep -v wip | head -1

        Show
        Yonik Seeley added a comment - Although, another alternative that doesn't have the shell expansion problem would be ls -r $ {data_dir} | grep snapshot . | grep -v wip | head -1
        Hide
        Bertrand Delacretaz added a comment -

        I think find -maxdepth is not supported on Solaris. And the -t option in my previous example was obviously wrong.

        I'm not sure if ls -r sorts by filename everywhere (but I have no evidence that it does not).

        The most portable version might be

        ls $

        {data_dir}

        | grep snapshot
        . | grep -v wip | sort -r | head -1

        Show
        Bertrand Delacretaz added a comment - I think find -maxdepth is not supported on Solaris. And the -t option in my previous example was obviously wrong. I'm not sure if ls -r sorts by filename everywhere (but I have no evidence that it does not). The most portable version might be ls $ {data_dir} | grep snapshot . | grep -v wip | sort -r | head -1
        Hide
        Yonik Seeley added a comment -

        I tried both versions out, and the "find" version was quicker (on Linux at least).
        System time was about the same, but "ls" had much higher user time.

        $ time find . -maxdepth 1 -name 'snapshot.*' | grep -v wip | head -1
        ./snapshot.20070411235957

        real 0m0.009s
        user 0m0.002s
        sys 0m0.008s

        $ time ls -r . | grep snapshot
        . | grep -v wip | head -1
        snapshot.20070412114504

        real 0m0.050s
        user 0m0.043s
        sys 0m0.009s

        Show
        Yonik Seeley added a comment - I tried both versions out, and the "find" version was quicker (on Linux at least). System time was about the same, but "ls" had much higher user time. $ time find . -maxdepth 1 -name 'snapshot.*' | grep -v wip | head -1 ./snapshot.20070411235957 real 0m0.009s user 0m0.002s sys 0m0.008s $ time ls -r . | grep snapshot . | grep -v wip | head -1 snapshot.20070412114504 real 0m0.050s user 0m0.043s sys 0m0.009s
        Hide
        Yonik Seeley added a comment -

        > I think find -maxdepth is not supported on Solaris

        Sigh... back to ls then.

        Show
        Yonik Seeley added a comment - > I think find -maxdepth is not supported on Solaris Sigh... back to ls then.
        Hide
        Bill Au added a comment -

        I confirmed that find -maxdepth does not work on Solaris. So it is back to ls. We should be OK as long as we don't use any wildcard that causes expansion.

        Show
        Bill Au added a comment - I confirmed that find -maxdepth does not work on Solaris. So it is back to ls. We should be OK as long as we don't use any wildcard that causes expansion.
        Hide
        Yonik Seeley added a comment -

        Updated patch:

        • switches back to "ls",
        • tries to determine if "maxdepth" is supported for the cleanup scripts that need to find -mtime
        • in snappuller, make the master find the latest snapshot instead of sending the complete "ls" across the network.

        This has not yet been tested.

        Show
        Yonik Seeley added a comment - Updated patch: switches back to "ls", tries to determine if "maxdepth" is supported for the cleanup scripts that need to find -mtime in snappuller, make the master find the latest snapshot instead of sending the complete "ls" across the network. This has not yet been tested.
        Hide
        Yonik Seeley added a comment -

        re-attaching with ASF perms (in the older JIRA version, the "grant license" option was first, and now it is last... hence I keep clicking the incorrect one)

        Show
        Yonik Seeley added a comment - re-attaching with ASF perms (in the older JIRA version, the "grant license" option was first, and now it is last... hence I keep clicking the incorrect one)
        Hide
        Yonik Seeley added a comment -

        Tested and committed.

        Show
        Yonik Seeley added a comment - Tested and committed.
        Hide
        Hoss Man added a comment -

        This bug was modified as part of a bulk update using the criteria...

        • Marked ("Resolved" or "Closed") and "Fixed"
        • Had no "Fix Version" versions
        • Was listed in the CHANGES.txt for 1.2

        The Fix Version for all 39 issues found was set to 1.2, email notification
        was suppressed to prevent excessive email.

        For a list of all the issues modified, search jira comments for this
        (hopefully) unique string: 20080415hossman2

        Show
        Hoss Man added a comment - This bug was modified as part of a bulk update using the criteria... Marked ("Resolved" or "Closed") and "Fixed" Had no "Fix Version" versions Was listed in the CHANGES.txt for 1.2 The Fix Version for all 39 issues found was set to 1.2, email notification was suppressed to prevent excessive email. For a list of all the issues modified, search jira comments for this (hopefully) unique string: 20080415hossman2

          People

          • Assignee:
            Unassigned
            Reporter:
            Yonik Seeley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development