Как настроить кластер mongodb для одновременной обработки 20К +

Question

Мое приложение использует MongoDB в качестве базы данных. Мы ожидаем 20K + одновременных подключений к кластеру mongodb. Как мне настроить сервер, если я хочу запустить mongodb на 20 серверах и расщепить кластер 20 способами?

Вот что я сделал до сих пор: На каждом из моих 20 серверов у меня есть один mongo (маршрутизатор), работающий на порту 30000, и на 3 серверах я запускаю серверы mongo config на порту 20000. Затем на каждом сервере я запускаю 3 экземпляра mongod. Один из основных. Другими словами, у меня 20 mongo, 3 mongo-config, 60 mongod-серверов (20 основных и 40 реплик).

Затем в моем приложении (которое также запускается на каждом сервере и подключается к localhost: 30000 mongos) я установил параметры mongoOptions так, чтобы connectionsPerHost = 1000.

Через 10-15 минут после запуска всех служб некоторые из них перестали работать с ssh. Эти серверы по-прежнему могут пинговать. Я подозреваю, что было слишком много соединений, и это привело к смерти сервера.

Мой собственный анализ выглядит следующим образом: 1K соединений на пул соединений означает для каждого основного сегмента, у него будет 1K * 20 (сегменты) = 20K открытых соединений одновременно. Возможно, на нескольких серверах будет работать более одного основного сервера, что удвоит или утроит количество подключений до 60 КБ. Так или иначе, mongod не может обрабатывать эти многочисленные соединения, хотя я изменил настройки системы, чтобы каждый процесс мог открывать гораздо больше файлов.

Вот что показывает «ulimit -a»:

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64000000
max memory size (kbytes, -m) unlimited
open files (-n) 320000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Кстати, я не указал --maxConns при запуске mongod / mongos, я также не изменил MONGO.POOLSIZE.

Дополнительный вопрос: если мои рассуждения верны, то на каждом первичном сервере будет выставлено общее количество требований одновременного подключения, что мне кажется неправильным, это почти означает, что кластер mongodb вообще не масштабируется. Кто-то скажет мне, что я не прав, пожалуйста?

Answer 1

Иногда ограничения не применяются к самому процессу.В качестве теста зайдите на один из серверов и получите pid для сервиса mongo, который вы хотите проверить, выполнив

ps axu | grep mongodb

, а затем выполните

cat /proc/{pid}/limit

. Это скажет вам, еслиограничения вступили в силу.Если ограничение не действует, вам нужно указать ограничение в файле запуска, а затем остановить - запустить службу mongo и протестировать снова.

Безошибочный способ узнать, происходит ли это, - привязать журнал монго на умирающем сервере и наблюдать за этими сообщениями «слишком много файлов».

Мы установили наш лимитдо 20000 на сервер и делайте то же самое на всех экземплярах mongod и mongos, и это похоже на работу.

Answer 2

По всей вашей кластерной архитектуре:

Запуск нескольких экземпляров mongod на одном и том же сервере обычно не очень хорошая идея, есть ли у вас какая-то особая причина для этого?Основной сервер каждого сегмента будет оказывать сильное давление на ваш сервер, репликация также увеличивает нагрузку, поэтому их смешивание не очень хорошо сказывается на производительности.IMO, вы должны иметь 6 осколков (1 мастер - 2 вторичных сервера) и предоставить каждому экземпляру свой собственный сервер.(Conf и экземпляр арбитра не слишком потребляют много ресурсов, поэтому можно оставить их на тех же серверах).

Answer 3

Мы запускаем репликацию из 4 осколков на 4 компьютерах.У нас есть 2 первичных сегмента шарда на 2 хостах, 2 реплики шарда на двух других боксах, арбитры и серверы конфигурации.

Мы получаем сообщения:

./checkMongo.bash: fork: retry: Resource temporarily unavailable
./checkMongo.bash: fork: retry: Resource temporarily unavailable
./checkMongo.bash: fork: retry: Resource temporarily unavailable
Write failed: Broken pipe 

Проверка ulimit -a:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 773713
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4096
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited   

Хорошо, возможно, мы достигли лимита процесса из-за сообщения fork.Вот как это проверить:

$ ps axo pid,ppid,rss,vsz,nlwp,cmd | egrep mongo
27442     1 36572   59735772 275 /path/mongod --shardsvr --replSet shard-00 --dbpath /path/rs-00-p --port 30000 --logpath /path/rs-00-p.log --fork
27534     1 4100020 59587548 295 /path/mongod --shardsvr --replSet shard-02 --dbpath /path/rs-02-p --port 30200 --logpath /path/rs-02-p.log --fork
27769     1 57948   13242560 401 /path/mongod --configsvr --dbpath /path/configServer_1 --port 35000 --logpath /path/configServer_1.log --fork

Итак, вы можете увидеть, что у mongod есть 275, 295 и 401 подпроцессов / потоков каждый.хотя сейчас я не достигаю предела, вероятно, раньше.Итак, решение: измените ulimit системы для пользователя, с которым мы работаем, с 1024 до 2048 (или даже неограниченно).Вы не можете изменить с помощью

ulimit -u unlimited

, если вы сначала не сделали sudo или что-то еще;У меня нет привилегий, чтобы сделать это.