我在mongodb谷歌小组中提出了这个问题,因为没有任何回复在这里发布.
我们有一个单节点mongo(版本2.0.1)实例.即使在每日存档之后,我们也会耗尽磁盘空间,因为mongo不会将空间返回到操作系统并尝试自行使用它.目前我们的设置非常稀疏,大约50%的空间闲置.您可以看到数据+索引大小约为1170 GB,而存储大小约为2158 GB,文件大小约为2368 GB.
db.stats()
{
"db" : "default",
"collections" : 106,
"objects" : 553988389,
"avgObjSize" : 2094.1392962010254,
"dataSize" : NumberLong("1160128855044"),
"storageSize" : NumberLong("2315777236208"),
"numExtents" : 1487,
"indexes" : 107,
"indexSize" : 97914435136,
"fileSize" : NumberLong("2543459500032"),
"nsSizeMB" : 16,
"ok" : 1
}
我们希望收回这个空间,因为这不是一个关键任务系统(它像一个日志的倾倒场)可以维持一个停机时间.我们不想花费在创建副本集上,我们也在物理数据中心,因此不希望仅为修复数据库附加额外的磁盘.
我想了解: -
修复数据库需要多少可用磁盘空间
- 修复数据库后我们希望恢复多少空间 - 修复数据库
需要多长时间.
- 如果所有修复数据库都在继续,那么杀死它并重启数据库是否安全.
我们的数据大量存在于一个集合中,因此紧凑集合是否优于修复数据库.
我们在CentOS 5.9机器上托管了haproxy 1.3.26,它具有2.13 GHz Intel Xeon处理器,作为许多服务的http和tcp负载均衡器,提供~2000请求/秒的峰值吞吐量.它已经运行了2年,但逐渐增加了流量和服务数量.
我们观察到即使在重新加载旧的haproxy过程后仍然存在.在进一步调查中,我们发现旧进程在TIME_WAIT状态下有许多连接.我们也看到了,netstat并且lsof花了很长时间.在引用http://agiletesting.blogspot.in/2013/07/the-mystery-of-stale-haproxy-processes.html时,我们介绍了option forceclose它,但它搞乱了各种监控服务,因此还原了它.经过进一步挖掘,我们意识到,在/proc/net/sockstat接近200K插座是tw(TIME_WAIT)状态,这在令人惊讶的是/etc/haproxy/haproxy.cfg maxconn已被指定为31000,并ulimit-n为64000.我们有timeout server和timeout client为300s我们改变30s,但没有太大用处.
现在的疑虑是: -