Details
-
Bug
-
Resolution: Fixed
-
Critical
-
7.1.3
-
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
For Gerrit Dashboard: MB-54560 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
183695,1 | MB-54560 Do not allocate 'xattrLen' number of map entries | neo | indexing | Status: MERGED | +2 | +1 |
183696,2 | MB-54560 Use NewParsedValueWithOptions insted of json unmarshall for xattr processing | neo | indexing | Status: MERGED | +2 | +1 |