Details
-
Bug
-
Resolution: Unresolved
-
Major
-
7.1.0
-
Untriaged
-
1
-
Unknown
Description
Currently we don't track sync write delete and write operations to the collection stats ops_delete and ops_store.
This means in situations where only sync writes are being used we can have zeroed stats for all collections which will look odd to the user. So we should fix this to remove the non obvious behavior.
richarddemellow@EMEA-MAC029:~/Documents/DevDocuments/Tickets/MB/MB-49767/ritesh-repo-feb/cbcollect_info_ns_1@172.23.121.127_20220208-235424$ grep "vb_778" stats.log | grep "ops_delete"
|
vb_778:ops_delete: 5771
|
vb_778:0x8:ops_delete 0
|
vb_778:0xa:ops_delete 0
|
vb_778:0xd:ops_delete 0
|
vb_778:0xe:ops_delete 0
|
vb_778:0xf:ops_delete 0
|
vb_778:0x12:ops_delete 0
|
vb_778:0x14:ops_delete 0
|
vb_778:0x15:ops_delete 0
|
vb_778:0x17:ops_delete 0
|
vb_778:0x1a:ops_delete 0
|
vb_778:0x1b:ops_delete 0
|
vb_778:0x0:ops_delete 0
|
vb_778:0x9:ops_delete 0
|
vb_778:0xb:ops_delete 0
|
vb_778:0xc:ops_delete 0
|
vb_778:0x10:ops_delete 0
|
vb_778:0x11:ops_delete 0
|
vb_778:0x13:ops_delete 0
|
vb_778:0x16:ops_delete 0
|
vb_778:0x18:ops_delete 0
|
vb_778:0x19:ops_delete 0
|
richarddemellow@EMEA-MAC029:~/Documents/DevDocuments/Tickets/MB/MB-49767/ritesh-repo-feb/cbcollect_info_ns_1@172.23.121.127_20220208-235424$ grep "vb_778" stats.log | grep 0x18
|
vb_778:0x18:name VolumeCollection16
|
vb_778:0x18:scope 0x0
|
vb_778:0x18:start_seqno 17
|
vb_778:0x18:high_seqno 834694
|
vb_778:0x18:persisted_high_seqno 834694
|
vb_778:0x18:items 1989
|
vb_778:0x18:disk_size 1833266
|
vb_778:0x18:ops_get 915
|
vb_778:0x18:ops_store 0
|
vb_778:0x18:ops_delete 0
|
The reason this doesn't work at the moment is that we perform the stats incrementation if the underlying code returns success. But in a sync write case it will return sync_write_pending as the sync write hasn't fully be satisfied yet.
VBucket::deleteItem(
|
...
|
if (ret == cb::engine_errc::success) { |
cHandle.incrementOpsDelete();
|
}
|
...
|
The stats incrementation for sync writes should be done at the point that the sync write has been resolved as it could be aborted. This means we could do it at the point we add the committed item into the checkpoint as we would have access to the collection's stats.