Mongo медленно работает на Amazon EC2

Я использую compose.io для размещения своего экземпляра Mongo. Мои данные становятся все больше, и оставаться там становится непомерно дорого, поэтому я хотел бы перейти на EC2, где у меня есть ~ 750 долларов в кредитах.

Проблема:

У меня есть конечная точка для аутентификации пользователя, которого я запускаю с моего локального хоста:

Когда мой API указывает на базу данных compose.io, время отклика ~ 200 мс.

Когда мой API указывает на мои новые экземпляры EC2 Mongo, его время отклика ~ 700 мс.

(Базы данных являются точными копиями)

Пинг инстанса EC2 составляет ~90-100 мс.

Коллекции были переиндексированы(), и экземпляр Mongo не загружается.

Подробнее об экземпляре EC2:

M3.большой

100 резервных операций ввода-вывода

Нулевой трафик/нагрузка.

Я не могу понять, почему Монго так медленно отвечает. Когда я аутентифицируюсь, в базе данных происходит несколько вещей (вот вывод из mongod.log)

2015-11-22T13:44:15.631+0000 [conn6] insert production.transactions query: { method: "POST", resource: "/api/v1.1/login", body: { password: "***********", email: "********" }, timezone: "America/New_York", agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36", _id: ObjectId('5651c6afdc24948b9f2e15e5'), created: new Date(1448199855577), __v: 0 } ninserted:1 keyUpdates:0 numYields:0 locks(micros) w:99 0ms
2015-11-22T13:44:15.631+0000 [conn6] command production.$cmd command: insert { insert: "transactions", documents: [ { method: "POST", resource: "/api/v1.1/login", body: { password: "***********", email: "*******" }, timezone: "America/New_York", agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36", _id: ObjectId('5651c6afdc24948b9f2e15e5'), created: new Date(1448199855577), __v: 0 } ], ordered: false, writeConcern: { w: 1 } } keyUpdates:0 numYields:0 locks(micros) w:83 reslen:40 0ms
2015-11-22T13:44:15.734+0000 [conn8] query production.users query: { email: "*******" } planSummary: IXSCAN { email: 1 } ntoskip:0 keyUpdates:0 numYields:0 locks(micros) r:125 nreturned:1 reslen:1553 0ms
2015-11-22T13:44:15.918+0000 [conn7] remove production.tokens query: { user_id: "5330d44ba6885a020005bc88" } ndeleted:0 keyUpdates:0 numYields:0 locks(micros) w:236 0ms
2015-11-22T13:44:15.918+0000 [conn7] command production.$cmd command: delete { delete: "tokens", deletes: [ { q: { user_id: "5330d44ba6885a020005bc88" }, limit: 0 } ], ordered: true, writeConcern: { w: 1 } } keyUpdates:0 numYields:0  reslen:40 0ms
2015-11-22T13:44:16.019+0000 [conn9] insert production.tokens query: { _id: "Tor9ke2lrt5Ooeifuh6hnCYFmmpDlWu8tRu2T2uZbgylFpx8EBlg1Aw7cQKQNc0I09zRhLrxdceV7lTf6UWl769ZMLX1cxlb0qksY8ssj1zme9uT1PkpNlIlNdBJE40S", user_id: "5330d44ba6885a020005bc88", expires: new Date(1448804120000), created: new Date(1448199855964), __v: 0 } ninserted:1 keyUpdates:0 numYields:0 locks(micros) w:73 0ms
2015-11-22T13:44:16.020+0000 [conn9] command production.$cmd command: insert { insert: "tokens", documents: [ { _id: "Tor9ke2lrt5Ooeifuh6hnCYFmmpDlWu8tRu2T2uZbgylFpx8EBlg1Aw7cQKQNc0I09zRhLrxdceV7lTf6UWl769ZMLX1cxlb0qksY8ssj1zme9uT1PkpNlIlNdBJE40S", user_id: "5330d44ba6885a020005bc88", expires: new Date(1448804120000), created: new Date(1448199855964), __v: 0 } ], ordered: false, writeConcern: { w: 1 } } keyUpdates:0 numYields:0 locks(micros) w:105 reslen:40 0ms
2015-11-22T13:44:16.128+0000 [conn10] command production.$cmd command: findAndModify { findandmodify: "users", query: { _id: ObjectId('5330d44ba6885a020005bc88') }, new: false, remove: false, upsert: false, update: { $set: { last_login: new Date(1448199856068) } }, writeConcern: { w: 1 } } update: { $set: { last_login: new Date(1448199856068) } } nscanned:1 nscannedObjects:1 nMatched:1 nModified:1 fastmod:1 keyUpdates:0 numYields:0 locks(micros) w:130 reslen:1624 0ms

person nwkeeley    schedule 22.11.2015    source источник
comment
Есть дополнительная информация, которая нам нужна для устранения проблемы, какую рабочую нагрузку вы читаете? письмо? или сбалансированный между обоими? Ваши данные помещаются в память или они всегда попадают на диск? Вы действительно достигли установленного ограничения ввода-вывода?   -  person datasage    schedule 22.11.2015
comment
1. нагрузка небольшая, только я выдаю этот запрос. Этот единственный запрос, как вы можете видеть, выполняет некоторые операции чтения и записи. Данные помещаются в память, вся база данных занимает ‹ 1 гигабайт, а экземпляр имеет 15 гигабайт памяти. Я не могу достичь заданного ограничения ввода-вывода, поскольку только я отправляю этот один запрос POST, который запускает эти ~ 5 запросов.   -  person nwkeeley    schedule 22.11.2015
comment
Время задержки напрямую связано с монго? или вы проходите через приложение? Если вы используете приложение, оно размещено в том же регионе, что и ваш экземпляр mongo?   -  person datasage    schedule 22.11.2015
comment
Задержка, с которой я сталкиваюсь, одинакова, если я получаю доступ к базе данных через приложение Heroku или через свой компьютер (localhost). Я хотел исключить сетевую задержку, поэтому я пропинговал ее и вижу ответ 90-100 мс от пинга.   -  person nwkeeley    schedule 22.11.2015
comment
Я забыл добавить, что экземпляр compose.io представляет собой набор реплик из 2 участников, мой EC2 — это единственный экземпляр mongo, если это имеет значение.   -  person nwkeeley    schedule 22.11.2015
comment
Реплика на самом деле не так сильно повышает производительность, ее основная цель — аварийное переключение, все записи идут на первичную, несмотря ни на что. Если я правильно понимаю, у вас есть задержка 100 мс между вашим экземпляром приложения и монго? Если это так, то каждый запрос/команда, которую вы выполняете в mongo, добавит задержку 100 мс к вашей конечной точке API.   -  person datasage    schedule 22.11.2015
comment
Давайте продолжим обсуждение в чате.   -  person nwkeeley    schedule 22.11.2015


Ответы (1)


Причина проблемы, по-видимому, заключается в настройке экземпляра mongo на западе США при размещении приложения на востоке США. Задержка в сети является причиной увеличения времени отклика.

person datasage    schedule 22.11.2015
comment
Ага, это было именно так. Heroku + Compose.io работают на востоке США, мой экземпляр EC2 был на западе США. Перемещение на восток США решило проблему. - person nwkeeley; 23.11.2015