kubectl apply -f cr.yaml with pause=true.have the system idle for a couple of hours.So there is zero traffic, no writes and whatsoever. We are currently “testing” on an offline installation. This could be very slow … and it seems you’ve experienced that. If the cache size isn’t ample enough to do that the cache eviction process will begin to keep the dataset size within the cache size. The recovery process needs to bring Btree pages from disk to apply the transaction (aka journal) updates to the documents.
We have reduced the WT cache and Percona Memory Engine cache to a couple of hundred MBs resp. Those writes will need the affected pages/blocks to be brought into the cache. The restore process is from the WT log → the collection, then in a next step from the oplog to the other databases. If the shutdown happened most of a minute after the last checkpoint and there were a lot of writes in that time, the restoring of them will take a long time but in theory you would estimate it to be < (1 min * a slow-down factor caused by bringing data from disk back into WT cache). The line with timestamp “T11:20:53.485+00:00” is another message bubbling up from the WT storage engine, but it’s a different event to the ones where the recovery of each WT transaction log file was being logged. When the log was separated into two sections by a paragraph, in the first comment, I thought it was not the same restart. while true do echo echo $(date -u) 'test' > /dev/null sleep 5 done WiredTigerConcurrentWriteTransactions: 128ĪntiAffinityTopologyKey: kubernetes.io/hostname WiredTigerConcurrentReadTransactions: 128 Image: percona/percona-server-mongodb:4.4.3-5ĮncryptionKeySecret: my-mongodb-cluster-mongodb-encryption-key => this behaviour means that if you store like 1 TB of data then you also need 1 TB of RAM - which I think is not a good idea. So either the WT cache or Percona Memory Engine cache settings are not respected or there is something else going on (and I dont think this is the file cache either). But after the startup it looks like the memory used up is the same as the data on disk. During the startup mongod seems always go through some recovery (?) even if the cluster has benn gracefully shut down with pause=true.
0 kommentar(er)
