Adding a new database gets longer the more databases exist (listDatabase hits again)

MongoDB Percona Operator for MongoDB
21

Hello @jamoser

My statement was about Percona Server for MongoDB. And I’m still pretty sure that diffing PSMDB and upstream MongoDB sources won’t show any additional listDatabases calls.

Now I see that you are talking about difference in behavior of Kubernetes Operators. Sorry I cannot help you with that but you can create bug report at jira.percona.com: please file ticket in “Percona Kubernetes Operator for Percona Server for MongoDB (K8SPSMDB)” project.

1 Like
22

Hi @Igor_Solodovnikov
Again we are talking abount MongoDB … so if I measure in my Java Code how long it takes to create the (first) collection, then I would strongly assume this has nothing to do in what “package” the MongoDB comes. As you can see in the log - it’s the log of MongoDB and I guess it doesnt matter whether it is from “Percona Server for MongoDB” or “Percona Distro for MongoDB Operator” or even “MongoDB Community Edition”.

The listDatabase shown in the log must come from somewhere … I am pretty sure it’s not the operator printing logs into the MongoDB log.

PS: or may be the problem is the listDatabases implementation in Percona MongoDB.

1 Like
23

@Igor_Solodovnikov

→ [PSMDB-1068] First creation of a collection of a new database takes very long because listDatabases is called - Percona JIRA

I would appreciate if this issue could be attacked as soon as possible.

1 Like
24

@jamoser

Thank you, i see that ticket.
I’m a bit confused by this long thread. Let’s clarify several questions:

  1. Is this true: you executed tests with Kubernetes operator by MongoDB corp and MongoDB Community Edition and in those tests there were no timing issue?
  2. You mentioned that MongoDB guys have fixed the issue in v5.2. So creation of the first collection can take longer than expected in MongoDB Community edition v4.4 and v5.0. Is this correct?
  3. Do you see any difference between configurations where mongod instance is installed manually versus mongodb instance installed by Kubernetes operator?
  4. Do you see any difference between single node mongodb and replica sets?
1 Like
25

@Igor_Solodovnikov

Is this true: you executed tests with Kubernetes operator by MongoDB corp and MongoDB Community Edition and in those tests there were no timing issue?
– Only MongoDB Community Edition and yes there was no timing issue

You mentioned that MongoDB guys have fixed the issue in v5.2. So creation of the first collection can take longer than expected in MongoDB Community edition v4.4 and v5.0. Is this correct?
– No - this is not correct. Fix in 5.2 is related to something else.

Do you see any difference between configurations where mongod instance is installed manually versus mongodb instance installed by Kubernetes operator?
– The only thing which is different is that Percona MongoDB runs additionally with sharding

Do you see any difference between single node mongodb and replica sets?
– I’ve run all setups as replica set

This log only appears in Percona and it looks it is related to sharding :

{“t”:{“$date”:“2022-04-07T22:19:45.814+00:00”},“s”:“I”, “c”:“COMMAND”, “id”:51803, “ctx”:“conn19676”,“msg”:“Slow query”,“attr”:{“type”:“command”,“ns”:“admin.$cmd”,“command”:{“listDatabases”:1,“maxTimeMS”:600000,“lsid”:{“id”:{“$uuid”:“4bb57c87-b141-400e-813b-9c4dc9b621c9”},“uid”:{“$binary”:{“base64”:“8oWwMUVUVSQBi/2N2mrozZM3ydIDKyYq6KEgTWZgcNU=”,“subType”:“0”}}},“$readPreference”:{“mode”:“primaryPreferred”},“$clusterTime”:{“clusterTime”:{“$timestamp”:{“t”:1649369980,“i”:2}},“signature”:{“hash”:{“$binary”:{“base64”:“3xYNVaFfPvki83klykHL+J1Re18=”,“subType”:“0”}},“keyId”:7083883792598827031}},“$audit”:{“$impersonatedUsers”:[{“user”:“percona_slow_0”,“db”:“percona_slow_0”}],“$impersonatedRoles”:[{“role”:“dbOwner”,“db”:“percona_slow_0”}]},“$client”:{“driver”:{“name”:“mongo-java-driver|legacy”,“version”:“3.12.8”},“os”:{“type”:“Windows”,“name”:“Windows 10”,“architecture”:“amd64”,“version”:“10.0”},“platform”:“Java/Oracle Corporation/1.8.0_191-b12”,“mongos”:{“host”:“luz-mongodb01-cluster-mongos-848fc699bc-x6k85:27017”,“client”:“127.0.0.1:52374”,“version”:“4.4.10-11”}},“$configServerState”:{“opTime”:{“ts”:{“$timestamp”:{“t”:1649369980,“i”:2}},“t”:1}},“$db”:“admin”},“numYields”:0,“reslen”:1478317,“locks”:{“ParallelBatchWriterMode”:{“acquireCount”:{“r”:25004}},“ReplicationStateTransition”:{“acquireCount”:{“w”:25004}},“Global”:{“acquireCount”:{“r”:25004}},“Database”:{“acquireCount”:{“r”:25003}},“Collection”:{“acquireCount”:{“r”:125327}},“Mutex”:{“acquireCount”:{“r”:25003}},“oplog”:{“acquireCount”:{“r”:1}}},“storage”:{},“protocol”:“op_msg”,“durationMillis”:5213}}
{“t”:{“$date”:“2022-04-07T22:19:45.826+00:00”},“s”:“I”, “c”:“SH_REFR”, “id”:24101, “ctx”:“ConfigServerCatalogCacheLoader-97”,“msg”:“Refreshed cached database entry”,“attr”:{“db”:“percona_slow_0”,“newDbVersion”:{“uuid”:{“$uuid”:“de9568ea-595e-4ede-b928-6b46bd1b22da”},“lastMod”:1},“oldDbVersion”:{},“durationMillis”:1}}
{“t”:{“$date”:“2022-04-07T22:19:45.827+00:00”},“s”:“I”, “c”:“SHARDING”, “id”:21950, “ctx”:“conn19676”,“msg”:“Setting this node’s cached database version”,“attr”:{“db”:“percona_slow_0”,“newDbVersion”:{“uuid”:{“$uuid”:“de9568ea-595e-4ede-b928-6b46bd1b22da”},“lastMod”:1}}}

=> I will run the whole test with Percona MongoDB Replicaset but without Sharding (if this is possible)

==> Should have done that earlier : as soon as Sharding is enabled, then listDatabases gets called (which kills the performance).

1 Like