码迷,mamicode.com
首页 > 数据库 > 详细

MongoDB副本集配置系列六:定位MongoDB慢的原因

时间:2015-06-17 13:22:05      阅读:214      评论:0      收藏:0      [点我收藏+]

标签:

1:想知道哪些操作拖慢了MongoDB的速度,首先需要检查当前正在执行哪些操作。

gechongrepl:PRIMARY> db.currentOp()
"opid" : 78891,#操作的唯一标识符,可通过它来终止操作
"active" : true,#true表示当前正在运行,false表示此操作已交出或在等待其他操作交出锁
"secs_running" : 1,#查看执行时间,可以通过该参数定位耗时的操作
"microsecs_running" : NumberLong(1081719),#
"op" : "getmore",#操作的类型,有查询、插入、更新、删除。数据库命令当查询处理
"ns" : "local.oplog.rs",
"query" : {
	
},
"client" : "192.168.91.132:55738",
"desc" : "conn1534",#可与日志信息联系起来,可以用来筛选相关的日志信息。
"threadId" : "0x7f91d77a5700",
"connectionId" : 1534,
"waitingForLock" : false,#表示该操作是否因正在等待其他操作交出锁而处于阻塞状态。
"numYields" : 0,#表示该操作交出锁,而使其他操作得以运行
"lockStats" : {
	"timeLockedMicros" : {
		"r" : NumberLong(68),
		"w" : NumberLong(0)
	},
	"timeAcquiringMicros" : {#表示该操作需要多长时间才能取得所需的锁
		"r" : NumberLong(7),
		"w" : NumberLong(0)
	}
}

  

条件查询

gechongrepl:PRIMARY> db.currentOp({"ns":"local.oplog.rs"})
这里只是举个例子:通常不会终止ns:local.oplog.rs的,因为复制的线程会持续的向同步源请求更多的操作。如果被异常终止,MongoDB会重启他们,但是会短暂的中断复制。

  

如果发现特别耗时的查询可以终止操作

gechongrepl:PRIMARY> db.killOp(5299)
update和find和remove操作可以被终止。因为他们已经交出了锁。正在占用锁或者等待其他操作交出锁的操作则无法被终止

怪异现象:终止了一个批量插入的语句,最后发现还是插入完成了。因为批量插入操作请求之后会写在缓冲区中的。即使终止了客户端发送请求,MongoDB还会处理缓冲区的写入操作。如果需要解决这种现象最好的方式是使用应答式写入,即每次写入操作都会等待上一次写入操作完成后才会进行下去。

2:打开系统分析器

查看当前的分析器级别:

gechongrepl:PRIMARY> db.getProfilingLevel()

  

 

gechongrepl:PRIMARY> db.setProfilingLevel(2)
{ "was" : 0, "slowms" : 100, "ok" : 1 }

db.system.profile.find().pretty()

把级别设置为2意味着分析器会记录所有内容。数据库的所有读写请求都会写到system.profile中。这样会造成性能的损失,因为每一次写操作都会增加额外的写入时间,而每一次读操作都要等待写锁(因为它必须在system.profile集合中写入记录)

 

gechongrepl:PRIMARY> db.setProfilingLevel(1,100)
{ "was" : 2, "slowms" : 100, "ok" : 1 }

db.system.profile.find().pretty()

级别1分析器会默认记录耗时大于100ms的操作。可以自定义阀值

 

gechongrepl:PRIMARY> db.setProfilingLevel(1,500)
{ "was" : 1, "slowms" : 100, "ok" : 1 } 

db.system.profile.find().pretty()

  

gechongrepl:PRIMARY> db.setProfilingLevel(0)
{ "was" : 1, "slowms" : 500, "ok" : 1 }

0就是关闭分析器 

 

3:计算MongoDB的空间消耗

_id存储为ObjectId类型,比存储为字符串类型效率更高

gechongrepl:PRIMARY> Object.bsonsize({_id:ObjectId()})
22
gechongrepl:PRIMARY> Object.bsonsize({_id:""+ObjectId()})
39
也可以直接对集合中的文档进行查询:
gechongrepl:PRIMARY> Object.bsonsize(db.users.findOne())
0

  

查看集合大小

gechongrepl:PRIMARY> db.test.stats()
{
	"ns" : "test.test",
	"count" : 239000,
	"size" : 19728112,
	"avgObjSize" : 82,
	"storageSize" : 37797888,
	"numExtents" : 8,
	"nindexes" : 1,
	"lastExtentSize" : 15290368,
	"paddingFactor" : 1,
	"systemFlags" : 1,
	"userFlags" : 1,
	"totalIndexSize" : 7456512,
	"indexSizes" : {
		"_id_" : 7456512
	},
	"ok" : 1
}
gechongrepl:PRIMARY> 

  

以MB为单位显示

gechongrepl:PRIMARY> db.test.stats(1024*1024)
{
	"ns" : "test.test",
	"count" : 239000,
	"size" : 18,
	"avgObjSize" : 82,
	"storageSize" : 36,
	"numExtents" : 8,
	"nindexes" : 1,
	"lastExtentSize" : 14,
	"paddingFactor" : 1,
	"systemFlags" : 1,
	"userFlags" : 1,
	"totalIndexSize" : 7,
	"indexSizes" : {
		"_id_" : 7
	},
	"ok" : 1
}

  

数据库大小:

gechongrepl:PRIMARY> db.stats()
{
	"db" : "test",
	"collections" : 6,
	"objects" : 239035,
	"avgObjSize" : 82.56948145669044,
	"dataSize" : 19736996,
	"storageSize" : 38879232,
	"numExtents" : 13,
	"indexes" : 3,
	"indexSize" : 7472864,
	"fileSize" : 67108864,
	"nsSizeMB" : 16,
	"dataFileVersion" : {
		"major" : 4,
		"minor" : 5
	},
	"extentFreeList" : {
		"num" : 0,
		"totalSize" : 0
	},
	"ok" : 1
}

  

4:使用mongostat和mongotop查看

  

 

MongoDB副本集配置系列六:定位MongoDB慢的原因

标签:

原文地址:http://www.cnblogs.com/xiaoit/p/4582858.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!