Моя установка: у меня есть 2 хоста и 2 шарда каждый.

  • Host1 имеет 2 осколка и является хозяином реплик
  • host2 имеет вторичные 2 шарда.

,

  • хост1: шард1 (репсет1), шард2 (репсет2)
  • хост2: шард1 (репсет1), шард2 (репсет2)

Также есть третий хост, который выступает в качестве арбитра.

У меня есть 50 потоков, пишущих случайным образом в оба шарда (используя хэш) через mongos с установленным REPLICA_SAFE WriteConcern для каждой вставки.

Вопросы:

  1. mongostat отображает около 90% заблокированных для обоих шардов в host1 и около 1% заблокированных для host2. Поскольку я использую REPLICA_SAFE, который предположительно выполняет запись на оба сервера, не должны ли блокировки быть одинаковыми?
  2. mongostat сообщает qr = 30 для обоих сегментов host1 и qw = 0 всегда. Так как я исполняю только пишет, как это возможно? Кроме того, на host2 все очереди сообщаются 0. Неисправности примерно одинаковы во всех шардах / хостах (около 80).
  3. netIn / netOut на вторичных серверах (host2) всегда составляет около 200 байт / с. Слишком низко.
  4. Монгос имеет 53 соединения, шарды хоста 1 имеют 71 и 71, а шарды хоста 2 имеют 9 и 8. Как это?
|источник

2 ответа2

1

Sivann,

Похоже, что вы используете Монго <2.0, если вы этого не сделаете, это может изменить ситуацию. Вы говорите, что используете REPLICA_SAFE, какой уровень W вы используете? Если это w:1, то вы просто подтверждаете, что запись на ваш первичный сервер прошла успешно, вы должны использовать w:2, чтобы подтвердить, что записи достигли вашего вторичного сервера.

  1. Репликация будет учитывать это. Ваши вставки принимают блокировку записи при вставке, и это блокирует репликацию от чтения данных для репликации.

  2. Усиливает пункт 1. Ваши чтения репликации стоят в очереди за записями от вставок. Скорее всего, проблема здесь в том, что вашей системе нужно постраничать в оперативную память, которую нужно прочитать для репликации, что приводит к ее блокировке. Вы также, вероятно, увидите конфликт между двумя первичными файлами за RAM по причинам, указанным Марком.

  3. Кажется низким, но не могу быть уверен. Вероятно, что ваши системы ожидают загрузки данных в ОЗУ или блокировки записи для их репликации.

  4. Вы можете увидеть, какие соединения идут куда-то из лог-файлов. Не зная, что там, где я не могу сказать вам, почему. Тем не менее, количество соединений здесь не кажется необоснованным.

|источник
1

Будьте осторожны с запуском нескольких экземпляров mongod на одном хосте. Они соревнуются в системной унификации:

Или запустите vm с выделенной оперативной памятью и процессором (так вы могли бы более эффективно использовать систему 24Core с MongoDB;)

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .