mongo shard имеет большое количество ошибок, но наверху показано только 8% памяти, используемой mongod

У меня есть 3 контроллера запросов и 6 шардов.

Я полагаю, вы имеете в виду три mongos машинки, АКА "роутеры"? Я никогда не слышал термин «контроллер запросов» применительно к MongoDB. Это достаточно нестандартно, чтобы усложнить вопрос.

Я выполняю большой пакетный импорт / обновление, и на трех контроллерах запросов я получаю около 200 запросов в секунду.

Итак, примерно 600 запросов в секунду попадают в вашу сегментированную среду.

Однако, исследуя осколки, я вижу множество ошибок, например 50 в секунду. Когда я запускаю серверы сегментов сверху, я вижу, что они используют только около 8% памяти. Для меня это означает, что mongo не настроен на серверах сегментов для использования всей доступной памяти. Я ошибся? Спасибо за любой совет.

Я предполагаю, что вы используете top на ОС хоста, а не mongotop против работающего члена шарда. Я понимаю, что вы захотите изучить природу отображения памяти MongoDB. Это огромная тема, и ее стоит прочитать на выходных, но вот заметки Клиффа:

• MongoDB использует управление памятью ОС хоста для кэширования файлов базы данных в ОЗУ.
• Тот факт, что процесс MongoDB занимает X объема ОЗУ, не означает, что он неэффективно использует объем Y.
• В Linux посмотрите на кешированную память, и большая часть ее, скорее всего, будет тем, в чем MongoDB «ошибается» в mongostat. Ошибка в mongostat не означает серьезных неисправностей на диске, это означает неисправности вне рабочего набора, которые mongod процесс используется. Тем не менее, он все еще может воздействовать на файлы в ОЗУ и работать практически так же быстро, как если бы память действительно принадлежала mongod.
• Если вы хотите определить, не хватает ли оперативной памяти MongoDB, вам нужно посмотреть на номера аппаратных ошибок хоста. Если вы совершаете серьезную ошибку и попадаете на диск для данных, тогда и только тогда в MongoDB не хватает памяти. Мне было неясно, были ли недостатки, о которых вы говорили, mongostat сбои, программные сбои ОС или жесткие сбои ОС.
• MongoDB использует память, которую хочет использовать MongoDB. Существует не так много способов оптимизации, которые можно было бы сделать, кроме использования прикоснуться в сценарии разминки, который втягивает данные в память с помощью грубой силы, а не позволяет mongod органически загружать рабочий набор в течение срока службы обычной загрузки запроса приложения. Однако для этого очень мало причин, за исключением быстрого нагрева памяти на новом первичном узле после понижения или быстрого нагрева памяти для нового. mongod PID (может быть, в результате перезагрузки, например).
• Привет, детки! Устранение неполадок с памятью MongoDB сложно! Пойдем читать об этом! ᕕ (ᐛ) ᕗ

Для меня вы не описали ничего необычного для MongoDB, если бы это было что-нибудь, кроме серьезных ошибок. В mongod сам по себе может содержать очень мало оперативной памяти, связанной с тем, что доступно на хосте, но кеш ОС будет заполнен файлами с отображением памяти, на которые ссылается MongoDB. Один из недавних экземпляров MongoDB, который я устранял, имел 144 ГБ ОЗУ и mongod использовала менее 10%, и все же ОС Linux на хосте имела более ста ГБ ОЗУ, указанную как кэшированную память, и не было никаких сбоев диска. Т.е. MongoDB был доволен.

Если бы в ОС произошел серьезный сбой, и используется свопинг ОС ... это было бы странно и проблема настройки уровня ОС.