MySQL批量拔出數據劇本。本站提示廣大學習愛好者：（MySQL批量拔出數據劇本）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL批量拔出數據劇本正文
這篇文章的目標是讓你曉得怎樣懂得你正在運轉的Mongdb能否安康。
mongostat詳解
mongostat是mongdb自帶的狀況檢測對象，在敕令行下應用。它會距離固准時間獲得mongodb確當前運轉狀況，並輸入。假如你發明數據庫忽然變慢或許有其他成績的話，你第一手的操作就斟酌采取mongostat來檢查mongo的狀況。
它的輸入有以下幾列：
1.inserts/s 每秒拔出次數
2.query/s 每秒查詢次數
3.update/s 每秒更新次數
4.delete/s 每秒刪除次數
5.getmore/s 每秒履行getmore次數
6.command/s 每秒的敕令數，比以上拔出、查找、更新、刪除的綜合還多，還統計了其余敕令
7.flushs/s 每秒履行fsync將數據寫入硬盤的次數。
8.mapped/s 一切的被mmap的數據量，單元是MB，
9.vsize 虛擬內存應用量，單元MB
10.res 物理內存應用量，單元MB
11.faults/s 每秒拜訪掉敗數（只要Linux有），數據被交流出物理內存，放到swap。不要跨越100，不然就是機械內存太小，形成頻仍swap寫入。此時要進級內存或許擴大
12.locked % 被鎖的時光百分比，盡可能掌握在50%以下吧
13.idx miss % 索引不射中所占百分比。假如太高的話就要斟酌索引是否是少了
14.q t|r|w 當Mongodb吸收到太多的敕令而數據庫被鎖住沒法履行完成，它會將敕令參加隊列。這一欄顯示了總共、讀、寫3個隊列的長度，都為0的話表現mongo毫無壓力。高並發時，普通隊列值會降低。
15.conn 以後銜接數
16.time 時光戳
應用profiler
似於MySQL的slow log, MongoDB可以監控一切慢的和不慢的查詢。
Profiler默許是封閉的，你可以選擇全體開啟，或許有慢查詢的時刻開啟。
> use test
switched to db test
> db.setProfilingLevel(2);
{"was" : 0 , "slowms" : 100, "ok" : 1} // "was" is the old setting
> db.getProfilingLevel()
2
檢查Profile日記
> db.system.profile.find().sort({$natural:-1})
{"ts" : "Thu Jan 29 2009 15:19:32 GMT-0500 (EST)" , "info" :
"query test.$cmd ntoreturn:1 reslen:66 nscanned:0 query: { profile: 2 } nreturned:1 bytes:50" ,
"millis" : 0}
3個字段的意義
1.ts：時光戳
2.info：詳細的操作
3.millis：操作所花時光，毫秒
不多說，此處有官方文檔。留意，形成滿查詢能夠是索引的成績，也能夠是數據不在內存形成是以磁盤讀入形成。
應用Web掌握台
Mongodb自帶了Web掌握台，默許和數據辦事一同開啟。他的端口在Mongodb數據庫辦事器端口的基本上加1000，假如是默許的Mongodb數據辦事端口(Which is 27017)，則響應的Web端口為28017
這個頁面可以看到
1.以後Mongodb的一切銜接
2.各個數據庫和Collection的拜訪統計，包含：Reads, Writes, Queries, GetMores ,Inserts, Updates, Removes
3.寫鎖的狀況
4.和日記文件的最初幾百行（CentOS+10gen yum 裝置的mongodb默許的日記文件位於/var/log/mongo/mongod.log)
可以參考左邊的截圖
db.stat()
獲得以後數據庫的信息，好比Obj總數、數據庫總年夜小、均勻Obj年夜小等
> use test
switched to db test
> db.stats()
{
"collections" : 9,
"objects" : 4278845,
"avgObjSize" : 224.56603031892953,
"dataSize" : 960883236,
"storageSize" : 1195438080,
"numExtents" : 59,
"indexes" : 13,
"indexSize" : 801931264,
"fileSize" : 6373244928,
"ok" : 1
}
db.serverStatus()
獲得辦事器的狀況
{
"version" : "1.6.5",
"uptime" : 7208469,
"uptimeEstimate" : 7138829,
"localTime" : "Wed Oct 26 2011 22:23:07 GMT+0800 (CST)",
"globalLock" : {
"totalTime" : 7208469556704,
"lockTime" : 4959693717,
"ratio" : 0.000688036992871448,
"currentQueue" : {
"total" : 0,
"readers" : 0,
"writers" : 0
}
},
"mem" : {
"bits" : 64,
"resident" : 3131,
"virtual" : 6172,
"supported" : true,
"mapped" : 4927
},
"connections" : {
"current" : 402,
"available" : 2599
},
"extra_info" : {
"note" : "fields vary by platform",
"heap_usage_bytes" : 832531920,
"page_faults" : 8757
},
"indexCounters" : {
"btree" : {
"accesses" : 2821726,
"hits" : 2821725,
"misses" : 1,
"resets" : 0,
"missRatio" : 3.543930204420982e-7
}
},
"backgroundFlushing" : {
"flushes" : 120133,
"total_ms" : 73235923,
"average_ms" : 609.6236920746173,
"last_ms" : 1332,
"last_finished" : "Wed Oct 26 2011 22:22:23 GMT+0800 (CST)"
},
"cursors" : {
"totalOpen" : 0,
"clientCursors_size" : 0,
"timedOut" : 238392
},
"repl" : {
"ismaster" : true
},
"opcounters" : {
"insert" : 269351,
"query" : 19331151,
"update" : 14199331,
"delete" : 1,
"getmore" : 145575,
"command" : 55982302
},
"asserts" : {
"regular" : 0,
"warning" : 0,
"msg" : 0,
"user" : 27,
"rollovers" : 0
},
"ok" : 1
}
須要關懷的處所：
1.connections 以後銜接和可用銜接數，聽過一個同業引見過，mongodb最年夜處置到2000個銜接就不可了（要依據你的機械機能和營業來設定），所以設年夜了沒意義。設個公道值的話，達到這個值mongodb就謝絕新的銜接要求，防止被太多的銜接拖垮。
2.indexCounters:btree:misses 索引的不射中數，和hits的比例高就要斟酌索引能否准確樹立。你看我的”missRatio” : 3.543930204420982e-7，很安康吧。所以miss率在mongostat外面也能夠看
3.其他的都能自說明，也不是檢查mongo安康狀態的症結，就不解釋了。
db.currentOp()
Mongodb 的敕令普通很快就完成，然則在一台忙碌的機械或許有比擬慢的敕令時，你可以經由過程db.currentOp()獲得以後正在履行的操作。
在沒有負載的機械上，該敕令根本上都是前往空的
> db.currentOp()
{ "inprog" : [ ] }
以下是一個有負載的機械上獲得的前往值樣例：
{ "opid" : "shard3:466404288", "active" : false, "waitingForLock" : false, "op" : "query", "ns" : "sd.usersEmails", "query" : { }, "client_s" : "10.121.13.8:34473", "desc" : "conn" },
字段名字都能自說明。假如你發明一個操作太長，把數據庫卡逝世的話，可以用這個敕令殺逝世他
> db.killOp("shard3:466404288")
MongoDB Monitoring Service
MongoDB Monitoring Service(MMS)是Mongodb廠商供給的監控辦事，可以在網頁和Android客戶端上監控你的MongoDB狀態。
