XMLWordPrintableJSON

Details

    • Sub-task
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 3.4.0
    • 3.4.0
    • capacity scheduler
    • None
    • Reviewed

    Description

      CapacitySchedulerConfiguration#getConfiguredNodeLabels scales poorly with respect to queue numbers (its O(n*m), where n is the number of queues and m is the number of properties set by each queue). During CS reinit, the node labels are often queried, however looking at the code:

      for (Entry<String, String> stringStringEntry : this) {
            e = stringStringEntry;
            String key = e.getKey();
      
            if (key.startsWith(getQueuePrefix(queuePath) + ACCESSIBLE_NODE_LABELS
                + DOT)) {
              // Find <label-name> in
              // <queue-path>.accessible-node-labels.<label-name>.property
              int labelStartIdx =
                  key.indexOf(ACCESSIBLE_NODE_LABELS)
                      + ACCESSIBLE_NODE_LABELS.length() + 1;
              int labelEndIndx = key.indexOf('.', labelStartIdx);
              String labelName = key.substring(labelStartIdx, labelEndIndx);
              configuredNodeLabels.add(labelName);
            }
          }
      

       This method iterates through ALL properties set in the configuration. For example in case of initialising 2500 queues, each having at least 2 properties:

      2500 * 5000 ~= over 12 million iteration + additional properties

      There are some ways to resolve this issue while keeping backward compatibility:

      1. Create a property like the original accessible-node-labels, which contains predefined labels. If it is set, then getConfiguredNodeLabels get the value of this property, otherwise it falls back to the old logic. I think accessible-node-labels are not used for this purpose (though I have a feeling that it should have been).
      2. Collect node labels for all queues at the beginning of parseQueue and only iterate through the properties once. This will increase the space complexity in exchange of not requiring intervention from user's perspective. 

      Attachments

        1. YARN-10780.001.patch
          27 kB
          Andras Gyori
        2. YARN-10780.002.patch
          27 kB
          Andras Gyori
        3. YARN-10780.003.patch
          23 kB
          Andras Gyori
        4. YARN-10780.004.patch
          25 kB
          Andras Gyori
        5. YARN-10780.005.patch
          25 kB
          Andras Gyori

        Issue Links

          Activity

            People

              gandras Andras Gyori
              gandras Andras Gyori
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: