Details
-
Bug
-
Resolution: Fixed
-
Critical
-
5.5.0, 5.5.1, 5.5.2, 5.5.3, 5.5.4, 5.5.5, 5.5.6, 6.0.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.5.1, 6.5.0, 7.0.0
-
1
-
KV-Engine Sprint 2021 July
Description
Problem
Currently the "dcp" and "dcpagg" stats are collated by the front-end thread. This can be an expensive operation, and hence the STAT command can take a significant time to return. This means the STAT operation is tying-up a front-and thread which means that operations that happen to be allocated to the same thread get delayed for an unacceptable length of time.
Solutions
- Move the expensive part(s) of these stat groups to a background task, allowing the client operation to EWOULDBLOCK and yield execution back to the front-end thread.
- Investigate what part(s) of these stat groups ns_server needs. If the stat(s) needed are cheap then consider new stat groups which only contain the specific elements ns_server needs.
Note we might want both of these; given that dcp and dcpagg are recorded by cbcollect_info and we wouldn't want to remove them there.
Attachments
Issue Links
- blocks
-
MB-44024 Timer creation failure due to LCB_ERR_TIMEOUT (201)
-
- Closed
-
-
MB-45125 SDK KV Write operations may timeout with default timeout of 2.5secs
-
- Closed
-
- causes
-
MB-47048 on_update_failure seen in 6.6.3 runs for timer tests
-
- Closed
-
- is triggering
-
DOC-8403 Release note timeouts may occur during cbcollect_info
-
- In Review
-
- relates to
-
MB-48816 TSan: Data race on CBStatCollector::addStat
-
- Closed
-