Как заявлено в описании механизма хранения WiredTiger, он обеспечивает возможность лучшего параллелизма за счет блокировки на уровне документа. Из эта почта:
WiredTiger масштабируется на современных многопроцессорных архитектурах. Используя различные методы программирования, такие как указатели опасности, алгоритмы блокировки, быстрая фиксация и передача сообщений, WiredTiger выполняет больше работы на ядро ЦП, чем альтернативные механизмы.
По какой-то причине моему варианту использования это не приносит пользы. У меня есть база данных с множеством одновременных записей (в основном обновлений), и такая нагрузка не может преодолеть ограничение в 2000 обновлений в секунду. Здесь mongostat 10 вывод:
insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time
3 780 1936 141 42 3|0 0.3 1.0 0 717.0M 289.0M 0|0 1|0 433k 6m 141 17:16:32
Пропускная способность диска не насыщена, iostat -x 10 вывод:
avg-cpu: %user %nice %system %iowait %steal %idle
20.56 0.00 20.31 0.10 0.10 58.93
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdb 0.00 5.80 0.00 102.50 0.00 6188.80 60.38 3.46 33.79 0.46 4.72
Учитывая все это, я предполагаю, что узким местом является использование ЦП, которое всегда стабильно на 100% все время для mongod процесс в top (от суммы 200%, что означает, что используется только один ЦП из двух). 58% простой с iostat также подтверждает это.
Существуют ли какие-либо методы, чтобы определить, использует ли хранилище WiredTiger блокировку на уровне документа и два ядра ЦП одновременно, как и должно быть? Или это могло произойти по каким-либо причинам, кроме ограничения мощности процессора?
Операции записи выполняются последовательно на одноядерном экземпляре. Операции чтения имеют параллелизм. Это то, что я понял из своих чтений.
Какая у вас установка клиента mongodb и какое оборудование?
По моему опыту тестирования различных механизмов хранения mongodb в разных системах, один экземпляр mongodb может довольно быстро попасть в стену при выполнении операций в секунду.
Это может быть из-за множества причин, таких как узкое место в полосе пропускания или время отправки. Чтобы узнать, пришло ли время отправки, вы можете попробовать запустить два экземпляра mongod бок о бок. Если оба они достигают 2000 обновлений в секунду и используют по 1 ЦП каждый, то вполне возможно, что время, необходимое mongod для отправки команд обновления, больше, чем время, необходимое вашей системе для выполнения некоторых команд обновления. Следовательно, у mongod не было бы причин использовать другое ядро процессора, потому что первое всегда готово к следующему обновлению (даже если оно находится на пределе).
Если вы по-прежнему получаете 2000 обновлений в секунду, и они по-прежнему используют только 1 ядро, то это будет другой проблемой, и мне нужно будет увидеть больше информации о настройке вашей системы, чтобы предположить, что это такое.
Если вы хотите использовать top, если mongoDB является основной загрузкой ЦП, вы должны иметь возможность использовать 1 вариант, (нажмите 1 после top запускается) или используйте альтернативный метод, как описано здесь: Как измерить использование отдельных ядер ЦП для процесса?
Для инструментов mongo это зависит от версии (инструменты изменены с 2.x на 3.x, поэтому использование инструментов для просмотра информации о блокировке будет зависеть от вашей версии), но db.serverStatus() должен предоставить вам информацию, которую вы ищете. Видеть Как мне увидеть статус блокировок на моих экземплярах mongod? для получения более подробной информации о конкретной версии. Не забудьте убедиться, что используемая вами версия MongoDB совпадает с версией в верхнем левом углу страницы (щелкните номер версии, чтобы изменить версию документации, которую вы просматриваете).