Estamos tentando otimizar melhor como estamos usando nossa instância do MongoDB. Parece que estamos rotineiramente obtendo altas porcentagens de bloqueio e estamos procurando ajudar a minimizar isso. Aqui está uma saída do mongostat:
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn time
1 107 186 0 0 196 0 3.06g 7.3g 333m 0 11.2 0 0|0 2|0 66k 224k 85 15:55:22
2 102 285 0 0 296 0 3.06g 7.3g 333m 0 15.7 0 0|0 2|0 89k 216k 84 15:55:23
2 79 325 0 0 335 0 3.06g 7.3g 333m 0 20.2 0 0|0 3|0 96k 149k 85 15:55:24
2 92 193 0 0 203 0 3.06g 7.3g 333m 0 10.9 0 1|1 6|1 63k 149k 86 15:55:25
3 102 235 0 0 245 0 3.06g 7.3g 331m 0 14.5 0 0|0 2|0 75k 177k 84 15:55:26
3 79 267 0 0 275 0 3.06g 7.3g 331m 0 16.5 0 1|0 2|0 80k 133k 86 15:55:27
2 66 219 0 0 226 0 3.06g 7.3g 264m 0 14.3 0 0|0 2|0 66k 112k 88 15:55:28
2 100 201 0 0 211 0 3.06g 7.3g 334m 0 10.2 0 0|0 3|0 67k 142k 87 15:55:29
3 118 227 0 0 244 0 3.06g 7.3g 322m 0 13.8 0 3|1 6|1 78k 150k 87 15:55:30
2 112 189 0 0 198 0 3.06g 7.3g 334m 0 10.8 0 0|1 2|2 64k 213k 87 15:55:31
2 80 266 0 0 278 0 3.06g 7.3g 246m 0 15.8 0 0|1 3|1 82k 179k 86 15:55:32
1 82 307 0 0 314 0 3.06g 7.3g 334m 0 18.1 0 0|0 2|0 89k 158k 86 15:55:33
2 94 278 0 0 285 0 3.06g 7.3g 334m 0 17.1 0 0|0 0|0 83k 184k 86 15:55:34
3 101 246 0 0 256 0 3.06g 7.3g 332m 0 14.2 0 0|0 1|0 82k 179k 86 15:55:35
3 99 203 0 0 213 0 3.06g 7.3g 334m 0 12.5 0 0|0 2|0 67k 154k 88 15:55:36
2 115 174 0 0 189 0 3.06g 7.3g 335m 0 11 0 1|0 3|0 63k 172k 88 15:55:37
2 97 199 0 0 209 0 3.06g 7.3g 335m 0 10.3 0 0|0 2|0 65k 192k 87 15:55:38
2 103 366 0 0 373 0 3.06g 7.3g 334m 0 23.5 0 1|4 3|4 107k 256k 85 15:55:39
2 105 338 0 0 349 0 3.06g 7.3g 334m 0 22.9 0 0|0 1|0 101k 207k 83 15:55:40
Isso é muito melhor do que costumava ser, graças a uma melhor indexação. No entanto, temos claramente mais a fazer. Coisas sobre este conjunto de dados:
- O hardware é uma caixa de 4 procedimentos, a média de carga geralmente está entre 1,3 e 1,9
- 4 GB de RAM
- O armazenamento com suporte de SAN está relatando latências com pico de 35ms, mas geralmente entre 5m e 20ms na maioria das vezes.
- As operações de E/S são muito baixas
- Os números 'qr' e 'qw' sugerem que não estamos enfrentando grandes filas.
Estamos usando o Mongo para rastrear metadados à medida que os documentos passam por nossa plataforma de processamento. Um documento Mongo é criado para cada documento real que temos (os documentos reais são os arquivos antigos do tipo Office). Cada estágio de processamento consulta algumas informações e, em seguida, grava as informações de volta (algumas vezes, um pouco delas). Dependendo dos dados com os quais estamos trabalhando, pode haver muitos estágios.
Esta é uma carga de trabalho de atualização pesada, portanto, a porcentagem de bloqueio é uma estatística de dimensionamento chave. Ainda não fragmentamos, em grande parte porque precisamos ver até onde uma única instância pode escalar antes de precisarmos fragmentar.
Que outras áreas precisamos investigar para reduzir a porcentagem de bloqueio ou apenas batemos na parede e precisamos fragmentar?
Essas são estatísticas interessantes. Acho que você pode estar sofrendo com o aumento do tamanho do documento em suas atualizações, onde o documento precisa ser copiado para um novo local no disco. Se esse for realmente o caso, você poderá recuperar parte dessa porcentagem de bloqueio preenchendo manualmente seus documentos. Acrescenta um pouco mais de complexidade na primeira inserção, mas não é tão ruim. Veja este documento nos documentos oficiais: http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-ManualPadding
Apenas uma ideia...