Users often consult: MongoDB CPU utilization is high, both full sprint, how should I do?
Encounter this problem, the possibility of 99.9999% is "on the user caused by an irrational" In this paper, from the application point of how to troubleshoot high MongoDB CPU utilization problem.
Step1: Request database analysis is being performed
Users can connect Mongo Shell, and executes db.currentOp () command, a database can see the operation currently being performed, the following is an example of the output of the command, the operation being performed in a logo. Focus on several fields:
- client: request which is initiated by the client?
- opid: opid operation, if necessary, can db.killOp (opid) operated by direct kill;
- secs_running / microsecs_running: This value focus, time is running on behalf of the request, if this value is particularly large, you have to pay attention to see if the request is reasonable;
- query / ns: this can see what it is doing to which the collection;
- lock *: with lock and some related parameters, Tell me what network you need to know can be a document, not detailed description.
{
"desc" : "conn632530",
"threadId" : "140298196924160",
"connectionId" : 632530,
"client" : "11.192.159.236:57052",
"active" : true,
"opid" : 1008837885,
"secs_running" : 0,
"microsecs_running" : NumberLong(70),
"op" : "update",
"ns" : "mygame.players",
"query" : {
"uid" : NumberLong(31577677)
},
"numYields" : 0,
"locks" : {
"Global" : "w",
"Database" : "w",
"Collection" : "w"
},
....
},
Here be clear about it, () to view the operation being performed by db.currentOp, in the end is what is the purpose?
Not to say that we want the operation being performed are listed, and then kill one by one by killOp; purpose of this step is to look at whether there are "unexpected" time-consuming request is being performed.
For instance, your business usually is not high CPU utilization, operation and maintenance management personnel connected to the database to perform a number of operations required to scan the entire table, then suddenly soared high CPU utilization, resulting in very slow response to your business, then we must focus on the next those execution time is very long operation.
Once the culprit is found, get the corresponding request opid executes db.killOp (opid) get rid of the corresponding request.
If you use an on-line, cpu utilization is high, and has been continued by the results db.currentOp also did not find anything unusual request, may enter into Step2 more in-depth analysis.
Step2: Analysis Database slow request
MongoDB profiling support functions, the implementation of the requested records to the same DB system.profile set in, profiling has three modes:
- Close profiling;
- Open profiling for all requests, performs all requests are recorded to system.profile set;
- Profiling for slow request, the request exceeds a certain threshold, set system.profile recorded.
By default the request, MongoDB the profiling function is turned off, the production environment is recommended to turn, slow request threshold may be customized according to needs, such as uncertainty, directly use the default value 100ms.
operationProfiling： mode: slowOp slowOpThresholdMs： 100
Based on the above configuration records, the request will be over 100ms to MongoDB system.profile DB's corresponding set, a default system.profile capped collection 1MB occupies most of the space.
See latest three slow request, {$ natrual: -1} representative of the ordinal numbers by reverse insertion
db.system.profile.find().sort({$natrual: -1}).limit(3)
In the case of open slow request profiling under (MongoDB cloud database is enabled by default profiling of slow requests), we were content to slow the requested analysis to identify possible optimization points, including common.
CPU Killer 1: full table scan
Full collection (table) scans COLLSCAN, when a query (or update, delete) request requires a full table scan, is very time consuming CPU resources, so when you log file or set of system.profile found COLLSCAN keywords, you have to attention, it is likely that these queries eat up your CPU resources; confirm, if such a request more frequently, it is best to optimize the indexing field for the query.
A query scans a number of documents, you can see the value in docsExamined system.profile, the larger the value, the greater the request CPU overhead.
> Keywords: COLLSCAN, docsExamined
CPU Killer 2: irrational Index
Sometimes, even if the query request to go the index, the implementation is very slow, usually because the establishment of reasonable not reasonable (or is itself the result of a lot of matches, so even taking the index, the request will not be spending a lot of optimization).
As shown below, assuming a data set, the value x small field (assuming only 1,2), while the y value of the field is very rich.
{X: 1, 1}
{x: 1, 2}
{x: 1, and 3}
......
{x: 1, and: 100000}
{x: 2, and 1 }
{x: 2, and 2}
{x: 2, and 3}
......
{x: 1, and: 100000}
To serve {x: 1: y: 2} such a query
db.createIndex ({x: 1}) ineffective, because the same x value too;
db.createIndex ({x:. 1, Y:}. 1) ineffective, because the same x value too;
DB. createIndex ({y: 1}) effect is good, because the same y value less;
db.createIndex ({y:. 1, X:}. 1) good results, because less the same y value;
As {y: 1} and {y: 1, x: 1} difference, reference index MongoDB principle and self-understood that the composite index official documentation.
Taking the index of a query, how many scans the index, you can view system.profile in the keysExamined field, the greater the value, the greater CPU overhead.
> Keywords: IXSCAN, keysExamined
CPU Killer 3: sorting large amounts of data
When a query request contains sort, if the sort can not, MongoDB will be carried out through an index to satisfy the memory Lee result ranking, and sorting this action in itself is very consuming CPU resources, optimization method is still indexed, often need to sort field indexing.
When you system.profile collection or log file found SORT keyword, you can consider to optimize sort through the index. When the request contains sorting phase, system.profile in the hasSortStage field will be true.
> Keywords: SORT, hasSortStage
A combination of indexing requires a full table scan, but also vaggeregation traversal, query, update, sorting and other actions; there are others, such as indexing, aggregationv and other operations can also be very consuming CPU resources, but also on the nature of these several scenes.
Step3: Service Capacity Assessment
After these two steps, you find that searching the entire database is very reasonable, all requests are efficiently gone index, basically no room for optimization, it is likely that your machine has reached the upper limit of the service capacity, you should upgrade the configuration (or by extension sharding).
Of course, the time when the best of circumstances, advance to MongoDB test to know in your scene, service capacity corresponding to the upper limit for the timely expansion, upgrade, rather than to the CPU with full resources, business has barely complete before going to the do the assessment.
Source: https: //www.ywnds.com/ p = 9010?
Source: Zhangyou Dong's blog