Подскажите пожалуйста, почему при выполнении команды db.serverStatus().globalLock: { totalTime: Long('342384277000'), currentQueue: { total: 0, readers: 0, writers: 0 }, activeClients: { total: 16, readers: 0, writers: 16 } } Для writers потолок всегда 16, вне зависимости от количества ядер на ВМ, или это количество зависит от другого параметра? И можно ли его регулировать? Версия монги 7.0.12

А больше значения я и не видел

С чего вы взяли что это потолок? globalLock.activeClients.writers The number of active client connections performing write operations.

Подскажите пожалуйста, почему при выполнении команды db.serverStatus().globalLock: { totalTime: Long('342384277000'), currentQueue: { total: 0, readers: 0, writers: 0 }, activeClients: { total: 16, readers: 0, writers: 16 } } Для writers потолок всегда 16, вне зависимости от количества ядер на ВМ, или это количество зависит от другого параметра? И можно ли его регулировать? Версия монги 7.0.12

Здравствуйте! А какая у вас проблема и как она проявляется?

В общем 5 инстансов сервиса, на каждом запущено по одному потоку, в каждом потоке транзакция, каждая транзакция выполняет bulk+upsert на 1000 операций)) Т.е. 5 параллельных транзакций в параллель идут на праймари, при этом увеличивается значение writeConflicts постоянно. На секондари сразу же копится эта очередь из replWriteWorker`ов, на цпу растет показатель iowait, хотя диски здоровые и по показателям R\w и iops до потолка им ещё далеко. Так вот вопрос, может ли эта ситуация возникать из-за конфликта транзакций на фоне блокировок за объект в бд и секондари копит очередь из-за того что ждет (w: majority) когда эта блокировка разрешится на праймари? И второй вопрос почему эта очередь не может подняться больше 16?

прям транзакции? и вам надо либо чтобы все записалось либо ничего, и именно в пачках по 1к?

Да

а что за данные и суть сохрания в монгу? данные из кафки небось и надо коммит проставить после вставки?

всё верно

уберите транзакции, добавьте уникальный индекс для контроля вставки дублей и работайте на атомарных апсертах

В общем 5 инстансов сервиса, на каждом запущено по одному потоку, в каждом потоке транзакция, каждая транзакция выполняет bulk+upsert на 1000 операций)) Т.е. 5 параллельных транзакций в параллель идут на праймари, при этом увеличивается значение writeConflicts постоянно. На секондари сразу же копится эта очередь из replWriteWorker`ов, на цпу растет показатель iowait, хотя диски здоровые и по показателям R\w и iops до потолка им ещё далеко. Так вот вопрос, может ли эта ситуация возникать из-за конфликта транзакций на фоне блокировок за объект в бд и секондари копит очередь из-за того что ждет (w: majority) когда эта блокировка разрешится на праймари? И второй вопрос почему эта очередь не может подняться больше 16?

Т.е. структуру с инстансами и потоками оставить те же, только bulk+upsert без транзакций?

да и надо будет накрутить только логику для дедупликации

если у вас идёт параллельный batch upsert и вы не можете гарантировать что каждый из батчей содержит уникальный набор документов — конфликты неизбежны тут есть три опции: * как выше сказали: не использовать транзакции * уменьшить размер батча * в пишущем клиенте формировать батчи таким образом, чтоб документы не пересекались

Так рут коз получается всё же в конфликтах?

https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md здесь почти все ответы на ваши вопросы 🙂 по поводу 200мс, тут есть несколько факторов 1) физическое летенси между нодами: быстрее чем RTT не будет 🙂 2) j флаг и journalCommitInterval, по умолчанию это 200мс https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md#commit-point-propagation

"как выше сказали: не использовать транзакции" - это попробуем "уменьшить размер батча" - так делали, только увеличивалось время записи "в пишущем клиенте формировать батчи таким образом, чтоб документы не пересекались" - над этим уже работаем чтобы инстансы писали в разные доки

Кстати ещё момент, в документации написано что параметр totalTickets в db.serverStatus().wiredTiger.concurrentTransactions меняется динамически, но при увеличении конфигурации он у нас таким же и остался, пришлось крутить вручную

А как быть с очередью из 16 ReplWriterWorker`ов на секондари? Что это вообще?)

Логику работы сервиса пока не меняли, но вот ещё одно интересное наблюдение: Очистили в коллекции часть данных и пока в ней было до ~40млн документов - всё обрабатывалось хорошо и быстро, видно было только что нагрузка на сервера медленно и постепенно растет с заполнением данными. А потом резко на 41млн+ начались проблемы, упала скорость обработки операций сильно и globalLock.activeClients.writers стали скакать с 5 до 40, и показатель PagesReadIntoCache на праймари поднялся с 200 до 3к, хотя со стороны сервиса не меняли ничего.

может быть вопрос в «индексах» на коллекции?

может быть вопрос в «индексах» на коллекции?

А тут после резких движений вполне себе не успели набрать нужную статистику

Нагрузочные тесты выполняются часов по 6-7 и столько же времени заполняется коллекция, если бы проблемы были с индексами, мы бы получили их на старте

Что с ними какие-то проблемы, они корректно работают. Просто не успели еще набрать статистику. Или данные поменялись из-за чего сами индексы уже не актуальны стали

Логику работы сервиса пока не меняли, но вот ещё одно интересное наблюдение: Очистили в коллекции часть данных и пока в ней было до ~40млн документов - всё обрабатывалось хорошо и быстро, видно было только что нагрузка на сервера медленно и постепенно растет с заполнением данными. А потом резко на 41млн+ начались проблемы, упала скорость обработки операций сильно и globalLock.activeClients.writers стали скакать с 5 до 40, и показатель PagesReadIntoCache на праймари поднялся с 200 до 3к, хотя со стороны сервиса не меняли ничего.

что с дисками?

Диски находятся в Y.cloud, у них лимиты 7000iops или 105Мб\с. При этом с течением времени медленно увеличивался показатель iowait, но сейчас нагрузка на них 80Мб\с и 4к iops

Меня смущает другой показатель: PagesReadIntoCache WT резко поднялся с 200 до 3к, при этом на нем же наблюдаются и сбросы данных из кэша WT. Т.е. движок начал чаще обращаться к диску и вычитывать бОльшие объемы, как будто они перестали помещаться в кэш WT, при этом его размер находился на уровне заполненности в 80% на протяжении всего НТ

ну вот считай уже достигнут уровень деградации для системы и надо расширять либо диски либо память, а лучше и то и то. Какой суммарный размер индексов и сколько оперативы?

Просто ожидания были такие, что WT, если еему будет нужно, возьмет себе из оперативы столько, сколько потребуется, но он что-то даже не собирается переступать дефолтный размер

под кеш wt выделяется 50% памяти это связано с тем, что в кеше wt документы хранятся как есть и сжимаются только при сбросе на диск на оставшиеся 50% памяти монга расчитывает как на запас по памяти для всего что не входит в кеш wt и на кеш фс который уже хранит сжатые данные по этому ручку размера кеша крутить в 99% случаев очень вредно

Да, но разве он в момент когда, допустим, ему нужно выгрузить больше данных в память, он не может переступить этот порог в 50%?

у вас сколько данных сейчас?

нет

под кеш wt выделяется 50% памяти это связано с тем, что в кеше wt документы хранятся как есть и сжимаются только при сбросе на диск на оставшиеся 50% памяти монга расчитывает как на запас по памяти для всего что не входит в кеш wt и на кеш фс который уже хранит сжатые данные по этому ручку размера кеша крутить в 99% случаев очень вредно

а сколько планируется?

это вот про эту часть

а сколько планируется?

160млн на старте и по 80млн в год, история с хранением на 5 лет

3/52*(160+80*5) = 32гб данные 7/52*(160+80*5)= 76гб индексы дешевле всего просто кинуть сверху ресурсов и посмотреть какой процент индексов реально используется

т.е. если я запускаю запрос без индекса который коллсканит мне всю коллекцию, то монга может съесть всю память и упасть от ООМ, а если ей просто нужно больше данных в свой кэш положить то не может?)

Не уверен что совсем понял что нужно сделать

если у вас кроме монги нет других сервисов на этой ноде и вы не крутили ручки которые влияют на то как монга использует память, то oom у монги фактически не возможен кеш wt под всё: индексы и данные если у вас индексы + данные в память не вмещаются, то collscan приведёт к тому что у вас данные из кеша будут вытеснятся и новые читаться. это называется сache trashing, так как кеш как кеш не работает и все операции идут через фс

Что значит "какой процент индексов реально используется" ? Там только дефолтный _id, один индекс который сейчас используется при upsert и ещё один который не используется сейчас вообще, но будет использоваться потом в будущем

а вы меняли cacheSizeGB?

а что db.hostInfo().system.memLimitMB показывает?

но в целом могу по вашим описаниям предложить следующее: 1) используйте дефолтные настройки, максимум что имеет смысл крутить: storage: directoryPerDB: true wiredTiger: engineConfig: journalCompressor: zstd directoryForIndexes: true collectionConfig: blockCompressor: zstd даже zstdCompressionLevel нет смысла трогать, там после дефолтных 6 редко когда есть ощутимая экономия в setParameter кроме enableFlowControl тоже крутить ничего не надо 2) размер индексов больше размера исходных данных в разжатом виде обычно симптом того, что индексы неэффективно спроектированы: _id не ObjectId, индексируемые поля указывают на {} а не на атомарные структуры или массив. это единственное что стоит оптимизировать 3) вычислительные ресурсы сейчас супердешевые. Вертикальное масштабирование самый простой и дешевый способ оптимизации 🙂 Сейчас в одну железку можно воткнуть где-то до 6TB памяти 1-2PB NVMe хранилища, до 240 ядер/480 тредов. это очень много ресурсов c 3Y TCO на уровне $10-12K/мес. Мой локальный тестовый стол это Epyc 7551P 32c/64t / 256Gb DDR4 / 4 × 2Tb nvme и всё это обошлось мне в <$2k

Нагрузочные тесты выполняются часов по 6-7 и столько же времени заполняется коллекция, если бы проблемы были с индексами, мы бы получили их на старте