简体   繁体   English

MongoDB sureIndex:对等重置连接

[英]MongoDB ensureIndex: Connection reset by peer

I have documents which contain a geo field like the below. 我有包含如下地理字段的文档。

"geo" : {
    "type" : "Point",
    "coordinates" : [
        37.44609999,
        -121.88355687
    ]
},

When I try to add a spatial index to this collection, it thinks for a while and then I get an error. 当我尝试向此集合添加空间索引时,它会思考一段时间,然后出现错误。

db.data.ensureIndex({'geo.coordinates': '2dsphere'})

Sat Sep 28 17:49:33.451 Socket recv() errno:104 Connection reset by peer 127.0.0.1:27017
Sat Sep 28 17:49:33.494 SocketException: remote: 127.0.0.1:27017 error: 9001 socket exception [RECV_ERROR] server [127.0.0.1:27017] 
Sat Sep 28 17:49:33.497 DBClientCursor::init call() failed
Sat Sep 28 17:49:33.634 Error: error doing query: failed at src/mongo/shell/query.js:78
Sat Sep 28 17:49:33.650 trying reconnect to 127.0.0.1:27017
Sat Sep 28 17:49:33.654 reconnect 127.0.0.1:27017 failed couldn't connect to server 127.0.0.1:27017

Any idea why this is happening? 知道为什么会这样吗? How can I debug this further? 如何进一步调试?

So I finally figure it out. 所以我终于弄清楚了。 I have Mongo installed on an Amazon EC2 Micro Instance. 我在Amazon EC2 Micro实例上安装了Mongo。 By default micro instances come with 613MB of memory and no swap space. 默认情况下,微型实例具有613MB的内存,没有交换空间。

The spatial index I was trying to create was over approximately 1 million documents. 我试图创建的空间索引大约有100万个文档。 So my guess is creating this index used up all available RAM and so with no swap space the Linux kernel had no choice but to kill the Mongo process. 因此,我的猜测是创建此索引会用完所有可用RAM,因此,没有交换空间,Linux内核别无选择,只能杀死Mongo进程。

The solution for anyone out there having the same problem is to follow this tutorial http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/ 对于存在相同问题的任何人,解决方案是遵循本教程http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the -性能/

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM