Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-19949

xdcr regression on Spock from Watson

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Critical
    • Resolution: Duplicate
    • 5.0.0
    • 5.0.0
    • performance
    • Untriaged
    • Centos 64-bit
    • Yes

    Description

      XDCR throughput dropped from expected 55556 to 3460 on Spock builds.

      Investigating whether this is tied in to KV Throughput in any way.

      Logs
      470 logs

      https://s3.amazonaws.com/cb-engineering/one/collectinfo-2016-06-15T155409-ns_1%40127.0.0.1.zip

      450 logs
      https://s3.amazonaws.com/cb-engineering/two/collectinfo-2016-06-15T160807-ns_1%40127.0.0.1.zip

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            I quickly went over the xdcr log file.

            1. xdcr replication ran fine. There had been no crashes, no xdcr restarts, no errors.
            2. DCP is not a bottleneck. The issue should be in target memcached or xdcr.

            yu Yu Sui (Inactive) added a comment - I quickly went over the xdcr log file. 1. xdcr replication ran fine. There had been no crashes, no xdcr restarts, no errors. 2. DCP is not a bottleneck. The issue should be in target memcached or xdcr.

            For Gomemcached , I see two changes (MB-19742, MB-19797) that are in master but not in watson.
            I would suggest running performance test against build before May 24th, 2016 and see if that uncover anything.

            -Thanks
            Ritesh

            ritesh.motlani Ritesh Motlani (Inactive) added a comment - For Gomemcached , I see two changes ( MB-19742 , MB-19797 ) that are in master but not in watson. I would suggest running performance test against build before May 24th, 2016 and see if that uncover anything. -Thanks Ritesh
            ketaki Ketaki Gangal (Inactive) added a comment - - edited

            I ve traced this back to the first available Spock build 470-448, for centos6 and I still see this issue.
            xdcr change logs here show nothing that can cause these problems, I ve taken a cursory look at the other component changes, but it is preferable that the owners of related components to validate whether they have significant check-ins into Spock at its earliest ( may 15th) builds.

            ketaki Ketaki Gangal (Inactive) added a comment - - edited I ve traced this back to the first available Spock build 470-448, for centos6 and I still see this issue. xdcr change logs here show nothing that can cause these problems, I ve taken a cursory look at the other component changes, but it is preferable that the owners of related components to validate whether they have significant check-ins into Spock at its earliest ( may 15th) builds.
            wayne Wayne Siu added a comment -

            Pavel Paulau
            Let us know what you may have found. Thanks.

            wayne Wayne Siu added a comment - Pavel Paulau Let us know what you may have found. Thanks.

            See also MB-20328 (Sherlock bug).

            pavelpaulau Pavel Paulau (Inactive) added a comment - See also MB-20328 (Sherlock bug).

            People

              pavelpaulau Pavel Paulau (Inactive)
              ketaki Ketaki Gangal (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty