Project

General

Profile

Actions

Bug #12920

closed

HEAD requests on large MPU Swift objects consistently timeout

Added by Andrew Williamson over 8 years ago. Updated over 8 years ago.

Status:
Duplicate
Priority:
High
Assignee:
-
Target version:
-
% Done:

0%

Source:
Community (user)
Tags:
swift
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Some Background:

- This issue has been reproduced in Firefly and Hammer
- We have seen this issue on a variety of cluster sizes including clusters as large as 100 osds and clusters as small as 3 nodes on openstack.
- We cannot reproduce this issue using the S3 API. It appears to be a Swift specific problem. The S3 api will HEAD the same file split into the same amount of chunks in 0.0078 seconds.
- We are using the mod_fastcgi (2.4.7) module with httpd version 2.4.6.
- Our fastcgi timeout is set to 1600 seconds.
- We disable the fastcgi wrapper in the fastcgi conf like so: "FastCgiWrapper Off"

Steps to reproduce our exact problem:

1. Create a Swift user with full permissions.

2. Create an 80GB file by doing the following command:

xfs_mkfile 85774958592 80GB.txt

3. Upload the file to Swift by breaking into 200MB object segments. We use python-swiftclient's cli interface like so:
swift --insecure upload test_head --segment-size 200000000 --segment-threads=10 80GB.txt

4. Attempt to head the file, here is how we are doing it: [[https://gist.github.com/Atothendrew/2c0e904f339d0e8d02fa]]. The request should timeout.

We can loop through HEAD requests against the ~400 parts manually by doing the following: [[https://gist.github.com/Atothendrew/6012e8a751cd136a1607]]. This usually takes around 15 seconds. We are very confused as to why it is taking so long to do a HEAD request against the base object.

Actions #1

Updated by Loïc Dachary over 8 years ago

  • Project changed from Ceph to rgw
  • Category deleted (22)
  • Affected Versions deleted (0.88)
Actions #2

Updated by Yehuda Sadeh over 8 years ago

  • Priority changed from Normal to High
Actions #3

Updated by Eric Beerman over 8 years ago

Looks like this issue is related to the fact that Swift static large objects are not supported currently in Ceph (http://tracker.ceph.com/issues/10647). Dynamic large objects are used instead, and the performance of calculating the object statistics for dynamic large objects seems to be quite bad for large objects. Specifically, looping through all parts to calculate the size of the object seems to take the longest.

Actions #4

Updated by Yehuda Sadeh over 8 years ago

  • Status changed from New to Duplicate

Duplicate of #12780

Actions

Also available in: Atom PDF