Mongodb - ExecutionStats executionTimeMillis намного больше, чем совокупное значение executionTimeMillisEstimate на каждом этапе. - PullRequest
0 голосов
/ 14 июля 2020

У меня есть агрегирование mon go с несколькими этапами, и часть этапа $match представляет собой операцию geoWithin по большому набору точек.

Я анализировал агрегирование, используя объяснение с ExecutionStats и заметил, что статистика выполнения выигрышного плана имела каждый этап с очень низким executionTimeMillisEstimate, но в целом executionTimeMillis было огромным. Я говорю о ~ 150-кратной разнице.

Я заметил, что queryPlanner имеет отклоненный план с запросом, использующим все второстепенные индексы, а не только индекс местоположения для geoWithin, который используется в выигрышном плане. Но поскольку выигрышный план кэшируется, я не думал, что это должно иметь большое значение.

Но опять же разница между ч / б Время слишком велика, чтобы быть только из-за отклоненного построения плана, в чем еще может быть причина для этого?

План выполнения:

{
    "executionSuccess": true,
    "nReturned": 101,
    "executionTimeMillis": 85264,
    "totalKeysExamined": 196,
    "totalDocsExamined": 315,
    "executionStages": {
        "stage": "FETCH",
        "filter": {
            "$and": [{
                    "something": {
                        "$eq": "a"
                    }
                },
                {
                    "other": {
                        "$eq": "abc"
                    }
                }
            ]
        },
        "nReturned": 101,
        "executionTimeMillisEstimate": 312,
        "works": 196,
        "advanced": 101,
        "needTime": 95,
        "needYield": 0,
        "saveState": 88,
        "restoreState": 88,
        "isEOF": 0,
        "docsExamined": 150,
        "alreadyHasObj": 150,
        "inputStage": {
            "stage": "FETCH",
            "filter": {
                "$or": [{
                        "location": {
                            "$geoWithin": {
                                "$centerSphere": [
                                    [
                                        0,
                                        1
                                    ],
                                    0.0000783927971443699
                                ]
                            }
                        }
                    },
                    {},
                    {}
                ]
            },
            "nReturned": 150,
            "executionTimeMillisEstimate": 312,
            "works": 196,
            "advanced": 150,
            "needTime": 46,
            "needYield": 0,
            "saveState": 88,
            "restoreState": 88,
            "isEOF": 0,
            "docsExamined": 165,
            "alreadyHasObj": 0,
            "inputStage": {
                "stage": "IXSCAN",
                "nReturned": 165,
                "executionTimeMillisEstimate": 0,
                "works": 196,
                "advanced": 165,
                "needTime": 31,
                "needYield": 0,
                "saveState": 88,
                "restoreState": 88,
                "isEOF": 0,
                "keyPattern": {
                    "location": "2dsphere"
                },
                "indexName": "location",
                "isMultiKey": false,
                "multiKeyPaths": {
                    "location": []
                },
                "isUnique": false,
                "isSparse": false,
                "isPartial": false,
                "indexVersion": 2,
                "direction": "forward",
                "indexBounds": {
                    "location": [
                        "[0, 1]",
                        ""
                    ]
                },
                "keysExamined": 196,
                "seeks": 32,
                "dupsTested": 0,
                "dupsDropped": 0
            }
        }
    }
}

1 Ответ

0 голосов
/ 14 июля 2020

Итого executionTimeMillis включает несколько вещей, которые не учтены в индивидуальном плане, например:

  • Затраченное время на планирование Планировщик запросов оценивает все индексы-кандидаты и планирует определить, какие из них тестировать. Это может занять ненулевое время для каждого плана кандидата и добавить к общему времени выполнения.
  • Получение блокировки При планировании проверяется только небольшая часть указателя / документов. После выбора плана он выполняется до завершения для получения статистики выполнения. Если выполняются другие операции, из-за которых исполнитель запроса ожидает блокировок, это увеличит общее время выше оценки
  • Задержка диска Подобно блокировкам, если чтение документов с диска происходит очень быстро на этапе планирования, но значительно медленнее во время выполнения, общее время будет больше, чем предполагаемое.

Вероятно, есть и другие соображения , Если я что-нибудь придумаю, я добавлю их сюда. Если кто-то еще помнит, что я забыл, не стесняйтесь предлагать отредактировать!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...