Meteor теряет соединение с базой данных

Я запускаю экземпляр Meteor в Digital Ocean и размещаю базу данных Mongo в Mongolab. Если сайт простаивает в течение нескольких часов и кто-то переходит на определенную страницу, Meteor, похоже, разрывает свое соединение с базой данных на 3-15 минут без каких-либо ошибок или предупреждений. Вот что мне удалось выяснить:

Сервер Meteor в DigitalOcean

• Продолжает работать, и Meteor.status() показывает активное соединение
• Загрузка процессора падает во время эпизода
• Будет и дальше обслуживать копии веб-приложения.

MongoDB в Mongolab

• Операции запросов упали почти до нуля
• Всплеск ошибок страницы
• Сетевой трафик падает до нуля.
• Все еще можно получить доступ и запросить напрямую.
• Другие серверы (рабочие), использующие ту же базу данных, продолжают работать в обычном режиме.

Я подозреваю, что это как-то связано со следующей публикацией:

Meteor.publish('spaceUtilSpace', function(view_id, space_id){
  if(!checkSpaceUtilPermissions(view_id, "View Reader", this.userId)) { this.ready(); return; }

  var thisUser = Meteor.users.findOne({_id: this.userId});
  var thisView = View_SpaceUtil.findOne({_id: view_id});

  if(thisView){
    var thisSpace = Spaces.findOne({_id: space_id});

    return [
      View_SpaceUtil.find({_id: view_id}),
      Bldgs.find({_id: thisSpace.localID.bldg_id}),
      Spaces.find({_id: space_id}),
      Schedule.find({"localID.space_id":space_id, startDateMs:{$lte:thisView.time.toDate}, endDateMs:{$gte:thisView.time.fromDate}})
    ]
  }
})

Я подозреваю, что проблема, скорее всего, в этой строке: Schedule.find({"localID.space_id":space_id, startDateMs:{$lte:thisView.time.toDate}, endDateMs:{$gte:thisView.time.fromDate}}), поскольку это моя самая большая коллекция (~ 80 000 документов, 150 МБ).

Сначала я подумал, что мне может просто понадобиться индекс для этого запроса, что обработка этого конкретного запроса просто занимала слишком много времени, но после создания индекса для {"localID.space_id":1, startDateMs:-1, endDateMs:1} у меня все еще была та же проблема.

У меня заканчиваются идеи, как это исправить, поэтому любые предложения будут невероятно полезными. Спасибо!

Дополнительная информация

Просматривая журналы Mongo, я обнаружил следующие две строки:

2015-12-04T08:11:09.904-0800 I QUERY    [conn51589] query myDatabase.schedule query: { localID.space_id: "mjEYjonRaFrrr8gcX", startDateMs: { $lte: 1451520000000.0 }, endDateMs: { $gte: 1262304000000.0 } } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 nscanned:0 nscannedObjects:78172 keyUpdates:0 writeConflicts:0 numYields:6664 nreturned:0 reslen:20 locks:{ Global: { acquireCount: { r: 13330 } }, MMAPV1Journal: { acquireCount: { r: 6665 } }, Database: { acquireCount: { r: 6665 } }, Collection: { acquireCount: { R: 6665 } } } 232971ms
2015-12-04T08:11:10.429-0800 I QUERY    [conn51593] query myDatabase.schedule query: { localID.space_id: "mjEYjonRaFrrr8gcX", startDateMs: { $lte: 1451520000000.0 }, endDateMs: { $gte: 1262304000000.0 } } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 nscanned:0 nscannedObjects:78172 keyUpdates:0 writeConflicts:0 numYields:610 nreturned:0 reslen:20 locks:{ Global: { acquireCount: { r: 1222 } }, MMAPV1Journal: { acquireCount: { r: 611 } }, Database: { acquireCount: { r: 611 } }, Collection: { acquireCount: { R: 611 } } } 128ms

Похоже, что проблема в том, что один запрос занимает невероятно много времени для выполнения и не позволяет делать новые запросы до тех пор, пока он не завершится.

Что меня сбивает с толку в отношении этих двух, так это то, что сам запрос идентичен, но «acquCount» для первого имеет 10-кратное содержимое, и для возврата потребовалось примерно в 2000 раз больше времени. Эти поля проиндексированы ... есть идеи, почему это могло произойти?