диагностирование mongodb основной сбой и ошибочное поведение
Чтобы быть уверенным в этом, мне нужно было бы лучше взглянуть на тенденцию с течением времени ( MMS может помочь), но вы можете столкнуться с проблемой, когда вы достигли максимального количества резидентной памяти для MongoDB в этом экземпляре - количество ошибок страниц не так велико, но я вижу небольшое падение резидентной памяти. Если есть нехватка памяти где-то еще (из другого процесса), возможно, вы удаляете страницы из MongoDB и / или вынуждены загружать страницы на диск чаще, чем должны (страница на диск в EBS выполняется довольно медленно).
Есть пара Здесь вы можете сделать более эффективное использование ОЗУ:
- Удалите ненужные индексы - они просто займут ценную ОЗУ, если будут использоваться - хорошими кандидатами на удаление являются отдельные индексы, которые являются крайним левым элементом составного индекса в другом месте. То, что можно удалить, действительно будет зависеть от вашего использования и схемы, поэтому все, что я могу дать, - это общие рекомендации.
- Настройте опережение чтения на томе EBS вниз - это противоречит тому, что вы будете прочтите о настройке томов EBS в целом, но слишком высокая установка опережения чтения на самом деле является тормозом для использования памяти, когда ваш профиль доступа является случайным, а не последовательным.
Чтобы взглянуть на настройки опережения чтения для тома, вы запускаете эту команду (требуется привилегии root / sudo):
sudo blockdev --report
Вывод будет примерно таким:
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 10737418240 /dev/xvda1
Столбец RA (256, который, я думаю, установлен по умолчанию на Amazon) - это то, что мы хотим здесь настроить. Для этого нужно выполнить что-то вроде этого:
blockdev --setra <value> <device name>
В приведенном выше примере я бы начал с уменьшения вдвое значения:
blockdev --setra 128 /dev/xvda1
Я более подробно расскажу о том, насколько низко вы должны установить это значение, и аргументы, лежащие в основе этого, в этом ответе , если вы хотите узнать больше. Обратите внимание, что изменение требует перезапуска процесса mongod, чтобы он вступил в силу.
После того, как вы выполнили обе эти вещи, вы сможете выжать больше производительности из ОЗУ на этом экземпляре xlarge. Если нет, или если давление на память исходит откуда-то еще и повышения эффективности недостаточно, то пора получить еще немного оперативной памяти.
Обновление хранилища EBS до тома RAID, как вы упомянули, или использование новых Provisioned IOPS и EBS оптимизированных инстансов (или вычислительных узлов SSD-кластера, если у вас есть деньги, чтобы сжечь) поможет «медленный»