Shulou(Shulou.com)05/31 Report--

This article shows you how to solve the problem of high mongodb utilization, the content is concise and easy to understand, and it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Step1: analyze the requests that are being executed by the database

Db.currentOp ()

Client: which client initiated the request?

Opid: the opid of the operation. If necessary, you can kill the operation directly through db.killOp (opid).

Secs_running/microsecs_running: this value focuses on the running time of the request. If this value is particularly large, you should pay attention to whether the request is reasonable.

Query/ns: this shows what operations are being performed on which collection

Lock*: also has some lock-related parameters

Step2: analyze database slow requests

MongoDB supports profiling function and records the execution of the request to the system.profile collection under the same DB. Profiling has three modes.

The profiling settings document is here. Read more about the official website.

Close profiling

Enable profiling for all requests and record the execution of all requests to the system.profile collection

For slow request profiling, record requests that exceed a certain threshold to the system.profile collection

Under the default request, the profiling function of MongoDB is disabled, and it is recommended to enable it in the production environment. The slow request threshold can be customized as needed. If in doubt, use the default value 100ms directly.

Set the slow request for 100ms

Db.setProfilingLevel (1, {slowms: 100})

When slow request profiling is enabled (slow request profiling is enabled by default in MongoDB cloud database), we analyze the content of slow request to find out the points that can be optimized. Common ones include.

The meaning of the output of the profiling result is here. Please see the official website documents.

CPU Killer 1: full table scan

Full set (table) scan COLLSCAN, when a query (or update, delete) request requires a full table scan, it consumes CPU resources very much, so when you find the COLLSCAN keyword in the system.profile collection or log file, you have to note that these queries are likely to eat your CPU resources; make sure that if such requests are frequent, it is best to optimize the fields of the query by establishing an index.

For a query on how many documents are scanned, you can look at the value of docsExamined in system.profile. The higher the value, the more expensive the request CPU.

> keywords: COLLSCAN, docsExamined

CPU Killer 2: unreasonable indexing

Sometimes, even if the query is indexed, the execution of the request is slow, usually because the reasonable establishment is not reasonable (or there are a lot of matching results, so that even if the index is taken, the request overhead will not be optimized.)

As shown below, suppose that for the data of a collection, the value of the x field is very small (suppose only 1, 2), while the value of the y field is rich.

{x: 1, y: 1}

{

{x: 1, y: 2}

{

{x: 1, y: 3}

.

.

{

{x: 1, y: 100000}

{

{x: 2, y: 1}

{

{x: 2, y: 2}

{

{x: 2, y: 3}

.

.

{

{x: 1, y: 100000}

To serve queries like {x: 1: y: 2}

Db.createIndex ({y: 1}) works well because there are few identical values for y.

D

Db.createIndex ({y: 1, x: 1}) works well because there are fewer values for the same y.

For an indexed query, how many indexes have been scanned, you can look at the keysExamined field in system.profile. The higher the value, the greater the CPU overhead.

> keywords: IXSCAN, keysExamined

CPU Killer 3: mass data sorting

When sorting is included in the query request, if the sorting cannot be satisfied by the index, MongoDB will sort the results in memory, and the sorting action itself is very CPU-intensive. The optimization method is still to build an index for the fields that often need to be sorted.

When you find the SORT keyword in the system.profile collection or log file, you can consider optimizing the sorting through the index. When the request contains a sort phase, the hasSortStage field in system.profile will be true.

> keywords: SORT, hasSortStage

= = MongodDB shard key chip key selection =

Mainly consider the "dispersion" and "frequency" of key. The higher the dispersion is, the better the data can be dispersed; the lower the frequency, the better to avoid hot spots.

= sample MongoDB connection string =

Correctly connect the posture of the sharding cluster

To connect the replication set correctly, you need to know the Connection String URI of MongoDB. All official driver supports Connection String connection to MongoDB sharding cluster.

Here are the main contents of Connection String

Mongodb:// [username:password@] host1 [: port1] [, host2 [: port2],... [, hostN [: portN] [/ [database] [? options]]

Mongodb:// prefix, which means this is a Connection String

Username:password@ needs to specify a user password if authentication is enabled

HostX:portX address list of multiple mongos

/ database authentication, the database to which the user account belongs

? options specifies additional connection options

The above content is how to solve the problem of high mongodb utilization. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.