Таблица за представяне за MongoDB

Производителността на базата данни влияе върху производителността на организацията и ние сме склонни да търсим бързо решение. Има много различни начини за подобряване на производителността в MongoDB. В този блог ще ви помогнем да разберете по-добре натовареността на вашата база данни и нещата, които могат да й причинят вреда. Познанията как да се използват ограничени ресурси са от съществено значение за всеки, който управлява производствена база данни.

Ще ви покажем как да идентифицирате факторите, които ограничават производителността на базата данни. За да гарантираме, че базата данни работи според очакванията, ще започнем от безплатния инструмент за наблюдение на MongoDB Cloud. След това ще проверим как да управляваме регистрационните файлове и как да проверяваме заявките. За да можем да постигнем оптимално използване на хардуерните ресурси, ще разгледаме оптимизацията на ядрото и други важни настройки на ОС. Накрая ще разгледаме репликацията на MongoDB и как да проверим производителността.

Безплатно наблюдение на производителността

MongoDB представи безплатен инструмент за наблюдение на производителността в облака за самостоятелни екземпляри и набори от реплики. Когато е активирано, наблюдаваните данни се качват периодично в облачната услуга на доставчика. Това не изисква никакви допълнителни агенти, функционалността е вградена в новия MongoDB 4.0+. Процесът е сравнително лесен за настройка и управление. След активиране с една команда, вие ще получите уникален уеб адрес за достъп до последните си статистики за ефективност. Имате достъп само до наблюдавани данни, които са били качени през последните 24 часа.

Ето как да активирате тази функция. Можете да активирате/деактивирате безплатното наблюдение по време на изпълнение, като използвате:

-- Enable Free Monitoring
db.enableFreeMonitoring()
-- Disable Free Monitoring
db.disableFreeMonitoring()

Можете също да активирате или деактивирате безплатното наблюдение по време на стартиране на mongod, като използвате настройката на конфигурационния файл cloud.monitoring.free.state или опцията на командния ред --enableFreeMonitoring

db.enableFreeMonitoring()

След активирането ще видите съобщение с действителното състояние.

{
    "state" : "enabled",
    "message" : "To see your monitoring data, navigate to the unique URL below. Anyone you share the URL with will also be able to view this page. You can disable monitoring at any time by running db.disableFreeMonitoring().",
    "url" : "https://cloud.mongodb.com/freemonitoring/cluster/XEARVO6RB2OTXEAHKHLKJ5V6KV3FAM6B",
    "userReminder" : "",
    "ok" : 1
}

Просто копирайте/поставете URL адреса от изхода за състоянието в браузъра и можете да започнете да проверявате показателите за ефективност.

Безплатният мониторинг на MongoDB предоставя информация за следните показатели:

• Времена за изпълнение на операцията (ЧЕТЕНЕ, ПИШЕ, КОМАНДИ)
• Използване на диска (МАКС. ПОЛЕЗЕН % ОТ ВСЯКО ДИСКОВЕ, СРЕДЕН ПОЛЕЗЕН % ОТ ВСИЧКИ ДИСКОВЕ)
• Памет (РЕЗИДЕНТСКА, ВИРТУАЛНА, КАРТИРАНА)
• Мрежа – Вход/Изход (БАЙТОВЕ ВХ., БАЙТОВЕ ИЗХОД)
• Мрежа – Брой заявки (NUM REQUESTS)
• Оператори (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Opcounters – Репликация (INSERT, QUERY, UPDATE, DELETE, GETMORE, COMMAND)
• Насочване на заявка (СКАНИРАНИ/ВЪРНАТИ, СКАНИРАНИ ОБЕКТИ/ВЪРНАТИ)
• Опашки (ЧИТАТЕЛИ, ПИСАЩИ, ОБЩО)
• Използване на системния процесор (ПОЛЗВАТЕЛ, НИЦА, KERNEL, IOWAIT, IRQ, SOFT IRQ, КРАДНА, ГОСТ)

За да видите състоянието на вашата безплатна услуга за наблюдение, използвайте следния метод:

db.getFreeMonitoringStatus()

ServerStatus и помощникът db.serverStatus() също включват безплатни статистически данни за наблюдение в свободното поле за наблюдение.

Когато работи с контрол на достъпа, потребителят трябва да има следните привилегии, за да активира безплатно наблюдение и да получи статус:

{ resource: { cluster : true }, actions: [ "setFreeMonitoring", "checkFreeMonitoringStatus" ] }

Този инструмент може да е добро начало за тези, на които им е трудно да четат изхода за състоянието на сървъра на MongoDB от командния ред:

db.serverStatus()

Безплатното наблюдение е добро начало, но има много ограничени възможности, ако имате нужда от по-усъвършенстван инструмент, може да искате да проверите MongoDB Ops Manager или ClusterControl.

Регистриране на операции с база данни

Драйверите на MongoDB и клиентските приложения могат да изпращат информация към регистрационния файл на сървъра. Тази информация зависи от вида на събитието. За да проверите текущите настройки, влезте като администратор и изпълнете:

db.getLogComponents()

Регистрационните съобщения включват много компоненти. Това е за осигуряване на функционална категоризация на съобщенията. За всеки от компонентите можете да зададете различна подробност на дневника. Текущият списък с компоненти е:

ACCESS, COMMAND, CONTROL, FTD, GEO, INDEX, NETWORK, QUERY, REPL_HB, REPL, ROLLBACK, REPL, SHARDING, STORAGE, RECOVERY, JOURNAL, STORAGE, WRITE.

За повече подробности относно всеки от компонентите вижте документацията.

Улавяне на заявки - Database Profiler

MongoDB Database Profiler събира информация за операции, които се изпълняват срещу mongod екземпляр. По подразбиране профайлърът не събира никакви данни. Можете да изберете да съберете всички операции (стойност 2) или тези, които отнемат повече време от стойността на slowms . Последният е параметър на екземпляра, който може да се контролира чрез конфигурационния файл mongodb. За да проверите текущото ниво:

db.getProfilingLevel()

За да обхванете всички заявки, задайте:

db.setProfilingLevel(2)

В конфигурационния файл можете да зададете:

profile = <0/1/2>
slowms = <value>

Тази настройка ще бъде приложена към един екземпляр и няма да се разпространява в набор от реплики или споделен клъстер, така че трябва да повторите тази команда за всички възли, ако искате да уловите всички дейности. Профилирането на база данни може да повлияе на производителността на базата данни. Активирайте тази опция само след внимателно обмисляне.

След това, за да изброите 10-те най-скоро:

db.system.profile.find().limit(10).sort(
{ ts : -1 }
).pretty()

За да изброите всички:

db.system.profile.find( { op:
{ $ne : 'command' }
} ).pretty()

И за списък за конкретна колекция:

db.system.profile.find(
{ ns : 'mydb.test' }
).pretty()

Регистриране на MongoDB

Местоположението на регистрационния файл на MongoDB е дефинирано в настройката за пътека на лог на вашата конфигурация и обикновено е /var/log/mongodb/mongod.log. Можете да намерите конфигурационния файл на MongoDB в /etc/mongod.conf.

Ето примерни данни:

2018-07-01T23:09:27.101+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Failed to connect to node1:27017 - HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Dropping all pooled connections to node1:27017 due to failed operation on a connection
2018-07-01T23:09:27.102+0000 I REPL_HB  [replexec-2] Error in heartbeat (requestId: 21589) to node1:27017, response status: HostUnreachable: Connection refused
2018-07-01T23:09:27.102+0000 I ASIO     [NetworkInterfaceASIO-Replication-0] Connecting to node1:27017

Можете да промените многословността на дневника на компонента, като зададете (пример на заявка):

db.setLogLevel(2, "query")

Регистрационният файл може да бъде значителен, така че може да искате да го изчистите преди профилиране. От конзолата на командния ред на MongoDB въведете:

db.runCommand({ logRotate : 1 });

Проверка на параметрите на операционната система

Ограничения на паметта

За да видите ограниченията, свързани с вашето влизане, използвайте командата ulimit -a. Следните прагове и настройки са особено важни за внедряването на mongod и mongos:

-f (file size): unlimited
-t (cpu time): unlimited
-v (virtual memory): unlimited
-n (open files): 64000
-m (memory size): unlimited [1]
-u (processes/threads): 32000

По-новата версия на скрипта за стартиране на mongod (/etc/init.d/mongod) има настройките по подразбиране, вградени в опцията за стартиране:

start()
{
  # Make sure the default pidfile directory exists
  if [ ! -d $PIDDIR ]; then
    install -d -m 0755 -o $MONGO_USER -g $MONGO_GROUP $PIDDIR
  fi

  # Make sure the pidfile does not exist
  if [ -f "$PIDFILEPATH" ]; then
      echo "Error starting mongod. $PIDFILEPATH exists."
      RETVAL=1
      return
  fi

  # Recommended ulimit values for mongod or mongos
  # See http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
  #
  ulimit -f unlimited
  ulimit -t unlimited
  ulimit -v unlimited
  ulimit -n 64000
  ulimit -m unlimited
  ulimit -u 64000
  ulimit -l unlimited

  echo -n $"Starting mongod: "
  daemon --user "$MONGO_USER" --check $mongod "$NUMACTL $mongod $OPTIONS >/dev/null 2>&1"
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/mongod
}

Ролята на подсистемата за управление на паметта, наричана още мениджър на виртуална памет, е да управлява разпределението на физическа памет (RAM) за цялото ядро ​​и потребителски програми. Това се контролира от параметрите на vm.*. Има две, които трябва да вземете предвид на първо място, за да настроите производителността на MongoDB - vm.dirty_ratio и vm.dirty_background_ratio .

vm.dirty_ratio е абсолютното максимално количество системна памет, което може да бъде запълнено с мръсни страници, преди всичко да бъде заредено на диска. Когато системата стигне до тази точка, всички нови I/O блокове, докато мръсните страници не бъдат записани на диска. Това често е източник на дълги I/O паузи. По подразбиране е 30, което обикновено е твърде високо. vm.dirty_background_ratio е процентът системна памет, която може да бъде запълнена с „мръсни“ страници — страници от памет, които все още трябва да бъдат записани на диск. Доброто начало е да преминете от 10 и да измерите ефективността. За среда с ниска памет 20 е добро начало. Препоръчителна настройка за мръсни съотношения на сървъри на бази данни с голяма памет е vm.dirty_ratio =15 и vm.dirty_background_ratio =5 или вероятно по-малко.

За да проверите коефициента на мръсно, изпълнете:

sysctl -a | grep dirty

Можете да зададете това, като добавите следните редове към “/etc/sysctl.conf”:

Размяна

На сървъри, където MongoDB е единствената работеща услуга, е добра практика да зададете vm.swapiness =1. Настройката по подразбиране е зададена на 60, което не е подходящо за система от база данни.

vi /etc/sysctl.conf
vm.swappiness = 1

Прозрачни огромни страници

Ако използвате своя MongoDB на RedHat, уверете се, че Transparent Huge Pages е деактивиран.
Това може да се провери от commnad:

cat /proc/sys/vm/nr_hugepages 
0

0 означава, че прозрачните големи страници са деактивирани.

Опции на файловата система

ext4 rw,seclabel,noatime,data=ordered 0 0

NUMA (неуниформен достъп до паметта)

MongoDB не поддържа NUMA, деактивирайте го в BIOS.

Мрежов стек

net.core.somaxconn = 4096
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_time = 120
net.ipv4.tcp_max_syn_backlog = 4096

NTP deamon

За да инсталирате NTP time server demon, използвайте една от следните системни команди.

#Red Hat
sudo yum install ntp
#Debian
sudo apt-get install ntp

Можете да намерите повече подробности за производителността на ОС за MongoDB в друг блог.

Обяснете плана

Подобно на други популярни системи за бази данни, MongoDB предоставя средство за обяснение, което разкрива как е била изпълнена операция с база данни. Резултатите от обяснението показват плановете на заявката като дърво от етапи. Всеки етап предава своите събития (т.е. документи или индексни ключове) на родителския възел. Листовите възли имат достъп до колекцията или индексите. Можете да добавите objasni('executionStats') към заявка.

db.inventory.find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} ).explain('executionStats');
or append it to the collection:
db.inventory.explain('executionStats').find( {
     status: "A",
     $or: [ { qty: { $lt: 30 } }, { item: /^p/ } ]
} );

Ключовете, за чиито стойности трябва да внимавате в изхода на изпълнението на горната команда:

• totalKeysExamined:Общият брой записи в индекса, сканирани за връщане на заявка.
• totalDocsExamined:Общият брой документи, сканирани за намиране на резултатите.
• executionTimeMillis:Общо време в милисекунди, необходимо за избор на план на заявка и изпълнение на заявка.

Измерване на производителността на забавяне на репликацията

Закъснението при репликация е забавяне между операция на първичния и прилагането на тази операция от oplog към вторичния. С други думи, той определя колко далеч е вторичният възел зад първичния възел, който в най-добрия случай трябва да бъде възможно най-близо до 0.

Процесът на репликация може да бъде засегнат по множество причини. Един от основните проблеми може да е, че вторичните членове изчерпват капацитета на сървъра. Големи операции за запис върху основния член, водещи до невъзможност на вторичните членове да възпроизведат оплоговете или до изграждане на индекс върху основния член.

За да проверите текущото забавяне на репликацията, изпълнете в обвивка на MongoDB:

db.getReplicationInfo()
db.getReplicationInfo() 
{
    "logSizeMB" : 2157.1845703125,
    "usedMB" : 0.05,
    "timeDiff" : 4787,
    "timeDiffHours" : 1.33,
    "tFirst" : "Sun Jul 01 2018 21:40:32 GMT+0000 (UTC)",
    "tLast" : "Sun Jul 01 2018 23:00:19 GMT+0000 (UTC)",
    "now" : "Sun Jul 01 2018 23:00:26 GMT+0000 (UTC)"

Изходът за състоянието на репликация може да се използва за оценка на текущото състояние на репликация и за определяне дали има някакво непредвидено забавяне на репликацията.

rs.printSlaveReplicationInfo()

Показва закъснението във времето между второстепенните членове спрямо първичните.

rs.status()

Показва задълбочените подробности за репликацията. Можем да съберем достатъчно информация за репликацията, като използваме тези команди. Надяваме се, че тези съвети дават бърз преглед на това как да прегледате производителността на MongoDB. Уведомете ни, ако сме пропуснали нещо.