Recentemente tivemos alto uso de CPU/memória e E/S em nosso MongoDB. Ao verificar os logs, tudo que encontrei foram alguns insertdurante esse período. Ao inspecionar os logs, notei que a maioria dos logs de inserção está bytesReadna seção de armazenamento. Portanto, suspeito que isso cause E/S e o armazenamento em cache dos dados cause muita memória.
Após o pico de inserção, a E/S e a CPU caíram, mas a memória permaneceu a mesma, o que foi resolvido após a reinicialização.
A leitura deste disco é normal com a operação de inserção? Estamos usando o Mongo v4.0 com WiredTigermecanismo de armazenamento na VM CentOS7.
2024-02-14T23:39:44.533+0800 I COMMAND [conn939845] insert db.user_log ninserted:1 keysInserted:11 numYields:0 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } storage:{ data: { bytesRead: 34390, timeReadingMicros: 140837 } } 141ms
2024-02-14T23:40:16.785+0800 I COMMAND [conn939845] insert db.user_log ninserted:1 keysInserted:11 numYields:0 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } storage:{ data: { bytesRead: 24150, timeReadingMicros: 506594 } } 507ms
Sim, neste caso, isso seria normal.
Os usuários do MongoDB WiredTiger para armazenamento, que armazena todos os dados e índices em uma estrutura de árvore b. Atualizar um btree exigirá a leitura da página raiz da árvore, depois das páginas internas dependendo da profundidade da árvore e, finalmente, da página folha onde os dados serão armazenados.
keysInserted:11indica que a inserção do documento também exigiu a inserção de 11 chaves de índice. Se esses fossem 11 índices diferentes, isso significaria ler também as páginas raiz, interna e folha de cada um deles.Se alguma dessas páginas já estivesse no cache, isso reduziria a quantidade total que precisa ser lida no disco, portanto, você poderá ver números variados significativos para inserções semelhantes.