Почему производительность mongodb настолько сильно отличается от двух похожих осколков?

Question

У меня есть два осколки 3 реплики машин каждый (одни и те же данные)

Куски являются достаточно хорошо распределены:

Shard events at events/xxx:27018,yyy:27018 
data : 6.82GiB docs : 532402 chunks : 59 
estimated data per chunk : 118.42MiB 
estimated docs per chunk : 9023 

Shard events2 at events2/zzz:27018,qqq:27018 
data : 7.3GiB docs : 618783 chunks : 66 
estimated data per chunk : 113.31MiB 
estimated docs per chunk : 9375 

Totals 
data : 14.12GiB docs : 1151185 chunks : 125 
Shard events contains 48.29% data, 46.24% docs in cluster, avg obj size on shard : 13KiB 
Shard events2 contains 51.7% data, 53.75% docs in cluster, avg obj size on shard : 12KiB 

Тем не менее, основной на одной стороне имеет почти 4x в vmsize и блокировать%, близкую к 90% (против 2% с другой), а также намного более высокий показатель btree. Это приводит к тому, что на этой машине происходит большое количество курсоров.

Оба осколка должны получать похожие типы запросов, а значения opcounter довольно близки.

Как я могу диагностировать это?

UPDATE неэффективная сторона, как представляется, используя Humongous объем памяти для данных, в том числе 100x пространство для индекса:

"ns" : "site_events.listen", 
    "count" : 544213, 
    "size" : 7500665112, 
    "avgObjSize" : 13782.59084586366, 
    "storageSize" : 9698657792, 
    "numExtents" : 34, 
    "nindexes" : 3, 
    "lastExtentSize" : 1788297216, 
    "paddingFactor" : 1.0009999991378065, 
    "systemFlags" : 1, 
    "userFlags" : 1, 
    "totalIndexSize" : 4630807488, 
    "indexSizes" : { 
      "_id_" : 26845184, 
      "uid_1" : 26664960, 
      "list.i_1" : 4577297344 
    }, 

против

"ns" : "site_events.listen", 
    "count" : 621962, 
    "size" : 7891599264, 
    "avgObjSize" : 12688.233789202555, 
    "storageSize" : 9305386992, 
    "numExtents" : 24, 
    "nindexes" : 2, 
    "lastExtentSize" : 2146426864, 
    "paddingFactor" : 1.0000000000917226, 
    "systemFlags" : 1, 
    "userFlags" : 1, 
    "totalIndexSize" : 45368624, 
    "indexSizes" : { 
      "_id_" : 22173312, 
      "uid_1" : 23195312 
    }, 

Answer 1

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

В вашем случае дополнительный индекс «list.i_1» имеет размер 4,2 ГБ и, безусловно, значительно повлияет на разницу в производительности.

Остальные мои комментарии более общие, а некоторые могут не соответствовать вашему примеру.

Вообще говоря, это не редкость, когда пользователи начинают с одного осколка (или не поставленного набора реплик), а затем добавляют второй осколок, чтобы взять половину нагрузки.

К сожалению, способ переноса данных в shard2 оставляет shard1 с фрагментированным хранилищем, как для данных, так и для индексов. Поскольку MongoDB использует файлы с отображением памяти, большие файлы в конечном итоге используют больше оперативной памяти, что вызывает больше нагрузки на подсистему ввода-вывода и, как правило, менее реалистично, чем более компактный shard2, который получил все свои данные в основном «сразу» и способный хранить аналогичное количество документов, используя меньше места.

Что вы можете сделать, чтобы вернуть shard1 с программой, это сжать затронутые коллекции или даже repairDatabase(), если есть несколько осколков коллекций. Последний вернет освобожденное пространство ОС, но даже если компактность не вернет пространство в ОС, он сохранит его в свободном списке, который будет использоваться при вставке большего количества данных, но существующие данные будут хорошо размещены в минимально возможном объеме пространства.

Обратите внимание, что в том же наборе реплик, хотя один из ваших праймериз - , больше, чем другой, вторичный значительно меньше. Это произойдет, если вторичная «повторная синхронизация» всех ее данных за один раз намного позже, чем при балансировке между черепами.В этом случае вы можете уйти в исходное положение и позволить более компактному вторичному захвату - он должен работать лучше, а между тем вы можете сжать или восстановить прежний первичный (вторичный). Как правило, рекомендуется использовать три узла реплик, чтобы вы не работали без защитной сетки при выполнении такого рода обслуживания.

Еще одно замечание, которое я сделаю, заключается в том, что даже если на обоих осколках имеется более или менее равномерно распределенная коллекция, у вас есть ряд дополнительных коллекций, которые живут на основном осколке для этой базы данных, что является более крупным осколком , Разница в размерах индекса, конечно, обусловлена ​​дополнительными индексами для дополнительных коллекций, которые существуют на shard1, а не shard2. Это нормально для базы данных, где только некоторые коллекции оштукатурены.

Существует не так много, что можно сделать о том, что дисбаланс, за исключением:

1. шард больший из unsharded коллекций или
2. перемещение половину unsharded коллекции в другую базу данных, которая будет иметь shard2 как его первичный осколок. Это разделит нечеткие коллекции между двумя осколками более «равномерно».