Я использую драйвер pecl mongo 1.4.x ( http://pecl.php.net/package/mongo/1.4.1 ), с настройкой, упомянутой в заголовке, в услугах умеренного трафика (запрос 5K – 10K за минуту).
И я обнаружил, что в mongoDB команда Auth принимает большую часть трафика, а скорость запроса на соединение составляет 30-50 в секунду.
Это серьезно влияет на производительность (коэффициент блокировки вверх, управление памятью не очень хорошо подходит)
И если я делаю netstat в ящике (у меня есть всего 5-8 ящиков), я вижу в целом 2-3K mongo-соединений (некоторые из WAIT некоторые из ESTABLISHED) в каждом поле.
Мой вопрос в том, как я могу уменьшить # подключения к mongoDB, как правильно настроить постоянное соединение?
Кажется, что способ постоянного взаимодействия, который работает в PECL, mongoDB Driver меняется с 1.2, затем 1.3, и он несколько отличается в 1.4.
Вот как я вызываю клиента с драйвером:
$ mongo = новый MongoClient (
«host1: 11004, host2: 11004», массив (
'replicaSet' => MG_REPLICASET,
'Пароль' => "superpasswd",
'Имя пользователя' => "MyUser",
'ДБ' => "MYDB",
'journal' => true,
"readPreference" => MongoClient :: RP_SECONDARY_PREFERRED
));
В версии 1.4 все соединения настойчивы, если вы не закрываете их самостоятельно – чего вы никогда не должны делать. Вы увидите соединение для каждой комбинации IP / username / password / database из каждого блока обработки PHP. В вашем случае, за каждый процесс PHPFPM. Чтобы уменьшить количество подключений, вам нужно иметь меньше комбинаций имени пользователя / пароля / базы данных. Однако с 8 ящиками и 50 процессами FPM и 3 узлами в вашем репликации вы уже находитесь в 1200 соединениях – даже без учета различий в базе данных / имени пользователя и пароле. Существует не так много, что вы можете сделать по этому поводу, но это не должно иметь большого влияния на производительность. Вы, скорее всего, нажмете ограничения RAM / медленного диска.
Я думаю, я нашел решение, чтобы избежать запроса exceessive mongo.
Нам нужно установить PHP_FCGI_MAX_REQUESTS (или pm. Max_requests в php-fpm) на большее число, поэтому процесс не будет слишком часто перерабатываться.
Также мне нужно убедиться, что pm.request_terminate_timeout не слишком мал, поэтому работников не будут убивать слишком часто.