Details
-
Bug
-
Resolution: Fixed
-
Critical
-
7.0.5
-
Security Level: Public
-
Untriaged
-
1
-
Unknown
Description
In one of the customer issues, it has been observed that projector was spending lot of time during XATTR processing. This ticket is to track the improvements in CPU at projector for XATTR processing
1050: if (event.Opcode == transport.DCP_MUTATION ||
|
. . 1051: event.Opcode == transport.DCP_DELETION) && event.HasXATTR() {
|
. . 1052: xattrLen := int(binary.BigEndian.Uint32(rq.Body))
|
. . 1053: xattrData := rq.Body[4 : 4+xattrLen]
|
. 29.05s 1054: event.RawXATTR = make(map[string][]byte, xattrLen)
|
. . 1055: for len(xattrData) > 0 {
|
. . 1056: pairLen := binary.BigEndian.Uint32(xattrData[0:])
|
. . 1057: xattrData = xattrData[4:]
|
. . 1058: binaryPair := xattrData[:pairLen-1]
|
. . 1059: xattrData = xattrData[pairLen:]
|
. 60ms 1060: kvPair := bytes.Split(binaryPair, []byte{0x00})
|
. . 1061: event.RawXATTR[string(kvPair[0])] = kvPair[1]
|
. . 1062: }
|
492: for _, xattr := range ie.xattrs {
|
. . 493: if _, ok := m.ParsedXATTR[xattr]; !ok {
|
. . 494: var val interface{}
|
. . 495: if len(m.RawXATTR[xattr]) != 0 {
|
. 21.66s 496: if err := json.Unmarshal(m.RawXATTR[xattr], &val); err != nil {
|
. . 497: arg1 := logging.TagStrUD(xattr)
|
. . 498: arg2 := logging.TagStrUD(m.Key)
|
. . 499: logging.Errorf("Error parsing XATTR %s for %s: %v",
|
. . 500: arg1, arg2, err)
|
. . 501: } else {
|
. 10ms 502: m.ParsedXATTR[xattr] = val
|
. . 503: }
|
. . 504: }
|
. . 505: }
|
. . 506: }
|
Attachments
Issue Links
- relates to
-
MB-54562 [BP to 6.6.6]- Optimise projector CPU during XATTR processing
- Closed
For Gerrit Dashboard: MB-54561 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
182942,1 | MB-54561 Do not allocate 'xattrLen' number of map entries | cheshire-cat | indexing | Status: MERGED | +2 | +1 |
182943,2 | MB-54561 Use NewParsedValueWithOptions insted of json unmarshall for xattr processing | cheshire-cat | indexing | Status: MERGED | +2 | +1 |