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

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查看