Question

我们的swift集群存在问题，swift版本为1.8.0。集群由3个存储节点+一个代理节点构成，我们有2次复制。每个节点都运行一个2TB sata HDD，操作系统在SSD上运行。流量是每分钟约300个1.3MB文件。文件大小相同。每个文件都使用X-expire-after上传，其值相当于7天。

当我们在大约3个月前启动群集时，我们上传的文件少得多（~150 / m），一切正常。由于我们对系统施加了更大的压力，因此对象过期器无法像上传一样快地使文件到期，从而慢慢填满服务器。

经过我们的分析，我们发现了以下内容：

这不是网络问题，接口没有超载，我们没有极端的开放连接数
这不是CPU问题，负载很好
它似乎不是RAM问题，我们有~20G免费64G

瓶颈似乎是磁盘，iostat非常具有启发性：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00    57.00    0.00  520.00     0.00  3113.00    11.97   149.18  286.21    0.00  286.21   1.92 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               2.00    44.00    7.00  488.00   924.00  2973.00    15.75   146.27  296.61  778.29  289.70   2.02 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     3.00   60.00  226.00  5136.00  2659.50    54.51    35.04  168.46   49.13  200.14   3.50 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00  110.00   91.00  9164.00  2247.50   113.55     2.98   14.51   24.07    2.95   4.98 100.00

读取和写入等待时间并不总是那么好:)，可以进入数千种范围的msecs，这非常可怕。

我们还看到来自节点端和代理中的许多ConnectionTimeout消息。

存储节点的一些示例：

Jul 17 13:28:51 compute005 object-server ERROR container update failed with 10.100.100.149:6001/sdf (saving for async update later): Timeout (3s) (txn: tx70549d8ee9a04f74a60d69842634deb)
Jul 17 13:34:03 compute005 swift ERROR with Object server 10.100.100.153:6000/sdc re: Trying to DELETE /AUTH_698845ea71b0e860bbfc771ad3dade1/container/whatever.file: Timeout (10s) (txn: tx11c34840f5cd42fdad123887e26asdae)
Jul 17 12:45:55 compute005 container-replicator ERROR reading HTTP response from {'zone': 7, 'weight': 2000.0, 'ip': '10.100.100.153', 'region': 1, 'port': 6001, 'meta': '', 'device': 'sdc', 'id': 1}: Timeout (10s)

还来自代理：

Jul 17 14:37:53 controller proxy-server ERROR with Object server 10.100.100.149:6000/sdf re: Trying to get final status of PUT to /v1/AUTH_6988e698bc17460bbfc74ea20fdcde1/container/whatever.file: Timeout (10s) (txn: txb114c84404194f5a84cb34a0ff74e273)
Jul 17 12:32:43 controller proxy-server ERROR with Object server 10.100.100.153:6000/sdc re: Expect: 100-continue on /AUTH_6988e698bc17460bbf71ff210e8acde1/container/whatever.file: ConnectionTimeout (0.5s) (txn: txd8d6ac5abfa34573a6dc3c3be71e454f)

如果所有推送到swift和object-expirer的服务都停止了，那么大部分时间磁盘利用率都保持在100％。没有async_pending事务，但有很多rsyncing正在进行，可能来自object-replicator。如果全部打开，几乎在任何给定的时刻都会有30-50甚至更多的异步交易。

我们考虑过缓解问题的不同解决方案，这基本上就是结果：

用于存储的SSD太贵了，所以不会发生
将另一个硬盘与RAID0群集中的每个硬盘配对（我们在swift中进行复制）
使用一些缓存，如bcache或flashcache

你们有没有遇到过这类问题的经历？寻找根本原因的任何提示/其他地方？是否有可能优化expirer / replicator性能？

如果需要任何其他信息，请告诉我。

由于

Answer 1

我已经看到了包含＆gt; 100万个对象的容器导致超时的问题（由于sqlite3 db无法获得锁定）...你能验证容器对象的数量吗？

Openstack Swift性能问题

1 个答案: