Mongodb Affecting the Graylog infra

We have the Graylog setup on 2 servers. each server has graylog-server, graylog-web, elasticsearch. Only one server has mongodb and the mongodb process starts taking lots of CPU thus increasing the unprocessed message on that server.

Please help

Why does the MongoDB mongod process use so many resources?

What’s in the logs of MongoDB?
:arrow_right: http://docs.graylog.org/en/2.3/pages/configuration/file_location.html

These are the major content

2017-08-08T15:49:36.827+0200 [conn50] query graylog2.sessions query: { session_id: "d0b50657-03bf-4029-95d3-deaf5fd8f7a8" } planSummary: COLLSCAN ntoskip:0 nscanned:7546 nscannedObjects:7546 keyUpdates:0 numYields:48 locks(micros) r:35219 nreturned:1 reslen:794 130ms
2017-08-08T15:49:36.836+0200 [conn12] query graylog2.sessions query: { session_id: "d945833f-48ed-486e-b0a9-f4abc586bdd2" } planSummary: COLLSCAN ntoskip:0 nscanned:9127 nscannedObjects:9127 keyUpdates:0 numYields:37 locks(micros) r:177962 nreturned:1 reslen:794 227ms
2017-08-08T15:49:36.840+0200 [conn43] query graylog2.sessions query: { session_id: "64029fcd-9488-4767-9e4d-b3497e84c9d1" } planSummary: COLLSCAN ntoskip:0 nscanned:9155 nscannedObjects:9155 keyUpdates:0 numYields:59 locks(micros) r:62079 nreturned:1 reslen:794 140ms
2017-08-08T15:49:36.845+0200 [conn34] query graylog2.sessions query: { session_id: "e883d03b-370e-4866-985b-8607f0801c90" } planSummary: COLLSCAN ntoskip:0 nscanned:9200 nscannedObjects:9200 keyUpdates:0 numYields:57 locks(micros) r:52717 nreturned:1 reslen:794 139ms
2017-08-08T15:49:36.866+0200 [conn54] query graylog2.sessions query: { session_id: "5fef368f-3bc0-47ac-a4e0-843feee1f315" } planSummary: COLLSCAN ntoskip:0 nscanned:9254 nscannedObjects:9254 keyUpdates:0 numYields:52 locks(micros) r:55367 nreturned:1 reslen:794 108ms
2017-08-08T15:49:36.868+0200 [conn33] query graylog2.sessions query: { session_id: "0d69c55c-ce9c-4f97-b4e0-529a9b2b90cd" } planSummary: COLLSCAN ntoskip:0 nscanned:9230 nscannedObjects:9230 keyUpdates:0 numYields:57 locks(micros) r:69392 nreturned:1 reslen:794 105ms
2017-08-08T15:49:36.876+0200 [conn32] query graylog2.sessions query: { session_id: "0571c071-d5c7-4a4b-ac20-18173433ddb0" } planSummary: COLLSCAN ntoskip:0 nscanned:9227 nscannedObjects:9227 keyUpdates:0 numYields:52 locks(micros) r:154790 nreturned:1 reslen:794 226ms
2017-08-08T15:49:36.907+0200 [conn20] query graylog2.sessions query: { session_id: "64029fcd-9488-4767-9e4d-b3497e84c9d1" } planSummary: COLLSCAN ntoskip:0 nscanned:9155 nscannedObjects:9155 keyUpdates:0 numYields:71 locks(micros) r:27998 nreturned:1 reslen:794 107ms
2017-08-08T15:49:36.913+0200 [conn14] query graylog2.sessions query: { session_id: "7df9a679-eec5-43a0-9e6b-a1bca851dcc9" } planSummary: COLLSCAN ntoskip:0 nscanned:9253 nscannedObjects:9253 keyUpdates:0 numYields:48 locks(micros) r:33159 nreturned:1 reslen:794 113ms
2017-08-08T15:49:36.916+0200 [conn46] query graylog2.sessions query: { session_id: "64029fcd-9488-4767-9e4d-b3497e84c9d1" } planSummary: COLLSCAN ntoskip:0 nscanned:9155 nscannedObjects:9155 keyUpdates:0 numYields:24 locks(micros) r:64684 nreturned:1 reslen:794 134ms
2017-08-08T15:49:36.918+0200 [conn22] query graylog2.sessions query: { session_id: "a387482d-841f-4ca4-b8d3-486130ba9961" } planSummary: COLLSCAN ntoskip:0 nscanned:9245 nscannedObjects:9245 keyUpdates:0 numYields:13 locks(micros) r:116405 nreturned:1 reslen:794 248ms
2017-08-08T15:49:36.918+0200 [conn15] query graylog2.sessions query: { session_id: "37c2da59-c80b-495e-9edb-c25d2c7a083e" } planSummary: COLLSCAN ntoskip:0 nscanned:9176 nscannedObjects:9176 keyUpdates:0 numYields:63 locks(micros) r:87842 nreturned:1 reslen:794 177ms
2017-08-08T15:49:36.919+0200 [conn40] query graylog2.sessions query: { session_id: "e883d03b-370e-4866-985b-8607f0801c90" } planSummary: COLLSCAN ntoskip:0 nscanned:9200 nscannedObjects:9200 keyUpdates:0 numYields:22 locks(micros) r:80960 nreturned:1 reslen:794 151ms
2017-08-08T15:49:36.929+0200 [conn58] query graylog2.sessions query: { session_id: "d6941d32-9130-41b5-bdd3-37991101a07b" } planSummary: COLLSCAN ntoskip:0 nscanned:9166 nscannedObjects:9166 keyUpdates:0 numYields:60 locks(micros) r:37756 nreturned:1 reslen:794 116ms
2017-08-08T15:49:36.933+0200 [conn17] query graylog2.sessions query: { session_id: "b934a4f9-4b3a-43cc-92fd-3acc0b19ef17" } planSummary: COLLSCAN ntoskip:0 nscanned:9225 nscannedObjects:9225 keyUpdates:0 numYields:36 locks(micros) r:74631 nreturned:1 reslen:794 162ms
2017-08-08T15:49:36.936+0200 [conn56] query graylog2.sessions query: { session_id: "5fef368f-3bc0-47ac-a4e0-843feee1f315" } planSummary: COLLSCAN ntoskip:0 nscanned:9254 nscannedObjects:9254 keyUpdates:0 numYields:15 locks(micros) r:38993 nreturned:1 reslen:794 107ms

It uses around 135% of CPU thus block elasticsearch process

The entire infra is affected because of the mongod taking up more than 100% of the process.
Please suggest.

Try creating an index for the session_id field in the sessions collection in MongoDB.

See https://docs.mongodb.com/manual/reference/method/db.collection.createIndex/ for details.

Out of interest, do you have many users or concurrent sessions in Graylog? If so, how many concurrent Graylog users are there?

How can I check the numbers of concurrent users in graylog?

The number of active sessions can be a good indicator for this.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.