Мы используем mongodb 3.4.14 с 8 ядрами, 32 ГБ оперативной памяти.Я выполнял нагрузочный тест с Jmeter, с 70 потоками у меня есть приемлемый вывод.Но с увеличением нагрузки SLA экспоненциально увеличивается, а пропускная способность резко снижается.Я попытался увеличить ulimit, и следующий шаг - это шардинг, кроме того, есть ли какая-либо другая оптимизация производительности, которую я могу сделать?
Обновление
@ Jeet, вот результаты:
- много запросов агрегации?Какая структура коллекции у вас есть, например:
Нагрузочный тест выполняется для одного запроса агрегации, и структура документа также имеет такой же набор полей.Исправление размера документа поможет?как я могу это сделать?
много ли вложенных массивов?
Ответ: Нет вложенных запросов.
Это один экземпляр или набор реплик?Попробуйте поместить набор реплик с чтением и записью в другой узел.
В настоящее время мы хотим работать только на одном узле.
Возвращают ли запросы данные из нескольких коллекций?
Нет, только 1 коллекция.
Убедитесь, что в вашем экземпляре происходит сбой страницы, на сколько% операций?
При нагрузке в 500 пользователей я не вижу много ошибок на странице, только 2-значные числа.
Проверьте журналы на наличие операций с высоким nscanned или scanAndOrder в периоды высокой блокировки / очереди и соответствующим индексом.
Как я могу это проверить?
Проверьте свои запросы для операторов, интенсивно использующих процессор, таких как $ all, $ push / $ pop / $ addToSet, а также обновления для больших документов и особенно обновления для документов с большими массивами (или большими массивами вложенных документов).
Да, при вышеуказанной загрузке ЦП заполнен и ответы задерживаются.Мы делаем groupBy, а затем сортируем по лимиту.
если в вашей базе данных много записей, имейте в виду, что только один ЦП на базу данных может записывать одновременно (из-за того, что поток удерживает блокировку записи).Рассмотрите возможность перемещения части этих данных в свою собственную базу данных.
Наша база данных в основном для чтения, коллекция будет заполняться один раз в день.
Помимо этого я пыталсяЧтобы выполнить простой тест, поместив приведенный ниже код в цикл for:
Document findQuery = new Document("userId", "Sham");
FindIterable<Document> find = collection.find(findQuery);
MongoCursor<Document> iterator = find.iterator();
Используется executor для запуска процесса:
ExecutorService executorService = Executors.newFixedThreadPool(100);
, даже при этом производительность замедляется, как будто900 мс, чтобы вернуться.
1 запрос = 150 мс на запрос
100 запрос = 900 мс на запрос
, когда я вижу статистику, как показано ниже для 500 пользователей:
insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 317M 28.0M 0|0 0|0 156b 45.1k 3 Oct 12 15:31:19.644
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 317M 28.0M 0|0 0|0 156b 45.1k 3 Oct 12 15:31:20.650
*0 *0 *0 *0 0 3|0 0.0% 0.0% 0 317M 28.0M 0|0 0|0 218b 46.1k 3 Oct 12 15:31:21.638
*0 *0 *0 *0 0 2|0 0.0% 0.0% 0 317M 28.0M 0|0 0|0 158b 45.4k 3 Oct 12 15:31:22.638
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 317M 28.0M 0|0 0|0 157b 45.4k 3 Oct 12 15:31:23.638
*0 376 *0 *0 0 112|0 0.0% 0.0% 0 340M 30.0M 0|0 0|0 64.9k 23.6m 26 Oct 12 15:31:24.724
*0 98 *0 *0 0 531|0 0.0% 0.0% 0 317M 27.0M 0|0 0|0 109k 6.38m 3 Oct 12 15:31:25.646
*0 *0 *0 *0 0 2|0 0.0% 0.0% 0 317M 27.0M 0|0 0|0 215b 45.6k 3 Oct 12 15:31:26.646
*0 *0 *0 *0 0 1|0 0.0% 0.0% 0 317M 27.0M 0|0 0|0 157b 45.1k 3 Oct 12 15:31:27.651
*0 *0 *0 *0 0 2|0 0.0% 0.0% 0 317M 27.0M 0|0 0|0 159b 45.8k 3 Oct 12 15:31:28.642