Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you the record and analysis of business card and MongoDB performance. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

What happened was the operation and maintenance, and the developers all told me that there was a card order in the business, and they all suspected it was the problem of the traditional database, and later I thought it was the problem of MQ. Finally, at noon, I found that because the operation of MONGODB was not strict (mainly because the operation of MONGODB DDL was different from that of the ordinary database, the development students had a lot of freedom), so the data had been written for a long time. However, the relevant maintenance work has not been informed of the relevant departments.

Generally speaking, the problems of the traditional database are found to be roughly the same in terms of operation means and methods, but it is not very clear how to find the problems and how to deal with the problems of MONGO DB as a NO SQL database.

Question 1, how to view slow queries

Generally speaking, there is such a problem in the maintenance of MONGODB, that is, try to avoid the impact of performance to close the system.profile, and then open it when something goes wrong, and then deal with it. I did the same thing at first, but later I found that it was not OK to deal with the problem in this way. First talk about why you want to do this, and then talk about why you have to open it later.

Reason for not opening system.profile

1 after the system encounters a large number of slow sentences, a large number of slow query records will be inserted into the system table.

2 this operation will cause possible secondary damage to the system performance.

Whether the train of thought is correct or not, I think that if there are monitoring or statistics for MONGODB slow queries, and an alarm can be made, then system.profile should be turned on, even if there will be some performance loss when there are a large number of slow queries, but it is important to find the problem at the first time. Instead of discovering it afterwards, it is better to always be prepared to find it in advance and solve the problem. Even if it is turned off then.

Here are two ways.

1 real-time monitoring, you can write a script to run regularly, query once a second

Db.currentOp ({"secs_running": {$gte: 3}})

The advantage of this query is that the slow statements of all different databases in the system will be pulled out and written directly to a log, or in a table written to mongodb, and then can be queried or displayed again.

2 mongodb profiler

This advantage is simple, but if you have a large number of databases on MONGODB, each database should be set to open, and may be less flexible than the first method. The advantage is that the information collected is richer and more targeted.

It depends on what you want. Of course, you can use both of them.

For example, if you want to find a query in system.profile that is slow and takes more than 1 second, display it from beginning to end with the most recent problematic statement. You can use the following statement

Db.system.profile.find ({op: {$eq: 'query'}})

{"millis": 1000}) .sort ({ts:-1}) .pretty ()

Of course, whether this is OK, in fact, almost, if developer asks you, HI has a slow query period of time, how the performance of the MONGODB machine, is the performance of the problem, and so on, it is estimated to take a little psychological, the key is, who knows the performance of the machine at that time.

In fact, compare with other databases, such as AWR reports, or DWV view systems, or some history tables in the sys library and preformance_schema, or from rich logs, get all the desired history and performance records output to beautiful analysis reports through pgBadger.

Then MONGODB can use a simple mongostat to record what you want, write a script, regularly switch logs and discard them, such as recording performance records for a week, of course, the interval can be adjusted larger, and then compare slow queries, you can easily tell developers or other people what MONGODB experienced at that time, dirty pages, data insertion, and CPU usage, and so on. Of course, if you install ops manager, management and performance monitoring will be more convenient and visual.

Of course, this is not over, you can also use some of the MONGODB tools included in the well-known tool collection in MYSQL to deal with such as slow queries, or to do a simple MONGODB AWR.

The above is the business card sheet and MongoDB performance record and analysis shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, 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.