Comme l'indique la description du moteur de stockage de WiredTiger, il permet d'améliorer la concurrence grâce au verrouillage au niveau des documents. D'après ce poste :
WiredTiger s'adapte aux architectures modernes à plusieurs processeurs. En utilisant une variété de techniques de programmation telles que les pointeurs aléatoires, les algorithmes sans verrouillage, le verrouillage rapide et le passage de messages, WiredTiger effectue plus de travail par cœur d'unité centrale que les moteurs alternatifs.
Pour une raison quelconque, mon cas d'utilisation ne semble pas en bénéficier. J'ai une base de données avec de nombreuses écritures simultanées (principalement des mises à jour), et ce type de charge ne semble pas pouvoir dépasser la limite de 2000 mises à jour par seconde. Voici l'exemple de la base de données mongostat 10 de la production :
insert query update delete getmore command % dirty % used flushes vsize res qr|qw ar|aw netIn netOut conn time
3 780 1936 141 42 3|0 0.3 1.0 0 717.0M 289.0M 0|0 1|0 433k 6m 141 17:16:32Le débit du disque n'est pas saturé, iostat -x 10 de la production :
avg-cpu: %user %nice %system %iowait %steal %idle
20.56 0.00 20.31 0.10 0.10 58.93
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvdb 0.00 5.80 0.00 102.50 0.00 6188.80 60.38 3.46 33.79 0.46 4.72Compte tenu de tout cela, je suppose que le goulot d'étranglement se situe au niveau de l'utilisation de l'unité centrale, qui est toujours stable à 100 %, tout le temps pour mongod dans le cadre de la top (sur un total de 200%, ce qui signifie qu'une seule unité centrale sur deux est utilisée). 58% de temps d'inactivité de iostat le confirme également.
Existe-t-il des méthodes permettant de déterminer si le stockage WiredTiger utilise le verrouillage au niveau des documents et deux cœurs d'unité centrale simultanément, comme il se doit ? Ou cela peut-il se produire pour des raisons autres que la limite de capacité de l'unité centrale ?
