作者:手机用户2502940165 | 来源:互联网 | 2014-05-28 16:53
今天试着在64位服务器上使用mongodb数据库,服务器硬盘磁盘阵列由10块140G硬盘构成,由于考虑采用Master/Salve机制备份这样就可以充份利用硬盘,所以采用了RAID5阵列。但是64位系统安装mongodb后,local数据库会直接用掉了70G。好浪费啊,赶紧查原因,发现mon
今天试着在64位服务器上使用
mongodb数据库,服务器硬盘磁盘阵列由10块140G硬盘构成,由于考虑采用Master/Salve机制备份这样就可以充份利用硬盘,所以采用了RAID5阵列。但是64位系统安装
mongodb后,local数据库会直接用掉了70G。好浪费啊,赶紧查原因,发现mongodb在64位默认使用5%空间做为日志存储。经过测试发现不采用Master/Salve机制,则不会有这种问题,32位系统下也不会有这种问题。由于mongodb可以循环利用日志空间,加上是做文件器,最后把oplogsize
先定到10G 测试一下了。之前的32位服务器上mongodb收1G物理文件,会用掉2G空间,这个浪费啊!
之后又碰到Mongodb映射文件吃内存的情况,mongodb会吃掉服务器上所有空闲内存,导致服务内全部被占用。这个时候,并发写入mongodb的效率极剧下降。但读的性能还是很高的,因为内存映射了大量热点,可以快速读取数据。
但是写就是问题了,首先服务器写入也要使用内存,这个时候写的效率下降了,其次在同步或备份的情况不可能再有多余的内存用于执行这类工作。感觉mongodb这一块内存控制应该设计成可控的,至少要保证Master服务的写性能和同步性能,而读的工作分担到salve服务器上,对master应该预余相当的内存以便于更好的工作。
现在头痛的问题,大量的文件要收录到mongodb中,不管是单线程还是多线程写入,当服务器内存使用完的情况,写的效率越来越低。只能不停的去释放掉这些内存,效率才能上去。这是目前碰到最头痛的问题。