Sharding handoffs creates a *ton* of container-server headers

Bug #1843313 reported by Tim Burke
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Fix Released
Undecided
Unassigned

Bug Description

Related: https://bugs.launchpad.net/swift/+bug/1839355

From IRC:

<+timburke> NM, why are we worried about [sharded handoff containers]? is it making the account stats flop around or something?
<NM> timburke: not sure if that is the reason but I'm getting some HTTP 503 when I try to list the container content. When I look at my proxy-error I got this message: " ERROR with Container server x.x.x.x:6001/sdb "#012HTTPException: got more than 126 headers"
<NM> If I curl direct to the container-server, it returns 1288 headers of X-Container-Sysmeta-Shard-Context-GUIDNUMBER
<NM> And they all have the same values: ""max_row": -1, "ranges_todo": 0, "ranges_done": 8, "cleaving_done": true, "last_cleave_to_row": null, "misplaced_done": true, "cursor": "", "cleave_to_row": -1, "ref": "SOME UID IN THE HEADER}

After calling broker.set_sharded_state() (which unlinks the retiring DB) we should clear the corresponding cleaving context -- otherwise they accumulate until the container becomes unusable.

Bonus points if we can clean up any existing stale contexts -- maybe do something like load all contexts, for each:

    if 'last_modified' not in context:
        context['last_modified'] = now
        save_context()
    elif context['last_modified'] + reclaim_age < now:
        delete_context()

and make sure we always update that last modified when saving changes.

Revision history for this message
Matthew Oliver (matt-0) wrote :

Maybe something like the attached patch.

I'll play with it and add some tests and push it up for review in the next day or so.

Revision history for this message
Matthew Oliver (matt-0) wrote :

I have pushed a patch for this: https://review.opendev.org/#/c/681970/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

Reviewed: https://review.opendev.org/681970
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=81a41da5420313f9cdb9c759bbb0f46c0d20c5af
Submitter: Zuul
Branch: master

commit 81a41da5420313f9cdb9c759bbb0f46c0d20c5af
Author: Matthew Oliver <email address hidden>
Date: Fri Sep 13 16:16:06 2019 +1000

    Sharding: Clean up old CleaveConext's during audit

    There is a sharding edge case where more CleaveContext are generated and
    stored in the sharding container DB. If this number get's high enough,
    like in the linked bug. If enough CleaveContects build up in the DB then
    this can lead to the 503's when attempting to list the container due to
    all the `X-Container-Sysmeta-Shard-Context-*` headers.

    This patch resolves this by tracking the a CleaveContext's last
    modified. And during the sharding audit, any context's that hasn't been
    touched after reclaim_age are deleted.

    This plus the skip empty ranges patches should improve these handoff
    shards.

    Change-Id: I1e502c328be16fca5f1cca2186b27a0545fecc16
    Closes-Bug: #1843313

Changed in swift:
status: New → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift 2.23.0

This issue was fixed in the openstack/swift 2.23.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (feature/losf)

Fix proposed to branch: feature/losf
Review: https://review.opendev.org/686864

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (feature/losf)
Download full text (26.4 KiB)

Reviewed: https://review.opendev.org/686864
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=bfa8e9feb51f2b10adfec3a741661a76fcf73216
Submitter: Zuul
Branch: feature/losf

commit cb76e00e90aea834c8f3dd8a6ca5131acd43663b
Author: OpenStack Proposal Bot <email address hidden>
Date: Fri Oct 4 07:05:07 2019 +0000

    Imported Translations from Zanata

    For more information about this automatic import see:
    https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

    Change-Id: I40ce1d36f1c207a0d3e99a3a84a162b21b3c57cf

commit 527a57ffcdefc03a5080b07d63f0ded319e08dfe
Author: OpenStack Release Bot <email address hidden>
Date: Thu Oct 3 16:35:36 2019 +0000

    Update master for stable/train

    Add file to the reno documentation build to show release notes for
    stable/train.

    Use pbr instruction to increment the minor version number
    automatically so that master versions are higher than the versions on
    stable/train.

    Change-Id: Ia93e0b690f47c6231423a25dfd6a108a60378a21
    Sem-Ver: feature

commit 8a4becb12fbe3d4988ddee73536673d6f55682dd
Author: Tim Burke <email address hidden>
Date: Fri Sep 27 15:18:59 2019 -0700

    Authors/changelog for 2.23.0

    Also, make some CHANGELOG formatting more consistent.

    Change-Id: I380ee50e075a8676590e755f24a3fd7a7a331029

commit bf9346d88de2aeb06da3b2cde62ffa6200936367
Author: Tim Burke <email address hidden>
Date: Thu Aug 15 14:33:06 2019 -0700

    Fix some request-smuggling vectors on py3

    A Python 3 bug causes us to abort header parsing in some cases. We
    mostly worked around that in the related change, but that was *after*
    eventlet used the parsed headers to determine things like message
    framing. As a result, a client sending a malformed request (for example,
    sending both Content-Length *and* Transfer-Encoding: chunked headers)
    might have that request parsed properly and authorized by a proxy-server
    running Python 2, but the proxy-to-backend request could get misparsed
    if the backend is running Python 3. As a result, the single client
    request could be interpretted as multiple requests by an object server,
    only the first of which was properly authorized at the proxy.

    Now, after we find and parse additional headers that weren't parsed by
    Python, fix up eventlet's wsgi.input to reflect the message framing we
    expect given the complete set of headers. As an added precaution, if the
    client included Transfer-Encoding: chunked *and* a Content-Length,
    ensure that the Content-Length is not forwarded to the backend.

    Change-Id: I70c125df70b2a703de44662adc66f740cc79c7a9
    Related-Change: I0f03c211f35a9a49e047a5718a9907b515ca88d7
    Closes-Bug: 1840507

commit 0217b12b6d7d6f3727a54db65614ff1ef52d6286
Author: Matthew Oliver <email address hidden>
Date: Wed Sep 4 14:30:33 2019 +1000

    PDF Documentation Build tox target

    This patch adds a `pdf-docs` tox target that will build
    PDF versions of our docs. As per the Train community goal:

      https://governance.openstack.org/tc/goals/selected/train/pdf-doc-...

tags: added: in-feature-losf
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (stable/stein)

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/689567

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (stable/stein)

Reviewed: https://review.opendev.org/689567
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=6e9e922cd6d6f7144605c5e959d3ff64f4bbc461
Submitter: Zuul
Branch: stable/stein

commit 6e9e922cd6d6f7144605c5e959d3ff64f4bbc461
Author: Matthew Oliver <email address hidden>
Date: Fri Sep 13 16:16:06 2019 +1000

    Sharding: Clean up old CleaveConext's during audit

    This is a combination of 4 commits:

    ==========

    Sharding: Clean up old CleaveConext's during audit

    There is a sharding edge case where more CleaveContext are generated and
    stored in the sharding container DB. If this number get's high enough,
    like in the linked bug. If enough CleaveContects build up in the DB then
    this can lead to the 503's when attempting to list the container due to
    all the `X-Container-Sysmeta-Shard-Context-*` headers.

    This patch resolves this by tracking the a CleaveContext's last
    modified. And during the sharding audit, any context's that hasn't been
    touched after reclaim_age are deleted.

    This plus the skip empty ranges patches should improve these handoff
    shards.

    (cherry picked from commit 81a41da5420313f9cdb9c759bbb0f46c0d20c5af)

    ----------

    Sharding: Use the metadata timestamp as last_modified

    This is a follow up patch from the cleaning up cleave context's patch
    (patch 681970). Instead of tracking a last_modified timestamp, and storing
    it in the context metadata, use the timestamp we use when storing any
    metadata.

    Reducing duplication is nice, but there's a more significant reason to
    do this: affected container DBs can start getting cleaned up as soon as
    they're running the new code rather than needing to wait for an
    additional reclaim_age.

    (cherry picked from commit 370ac4cd70489a49b2b6408638c9b35006f57053)

    ----------

    Make sharding methods with only one job

    (cherry picked from commit f56071e57392573b7aea014bba6757a01a8a59ad)

    ----------

    sharding: Update probe test to verify CleavingContext cleanup

    (cherry picked from commit 9495bc0003817805750dd78f3d93dd1a237f1553)

    ==========

    Co-Authored-By: Clay Gerrard <email address hidden>
    Co-Authored-By: Tim Burke <email address hidden>
    Change-Id: I1e502c328be16fca5f1cca2186b27a0545fecc16
    Closes-Bug: #1843313

tags: added: in-stable-stein
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/swift 2.21.1

This issue was fixed in the openstack/swift 2.21.1 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.