我们的swift集群有一个问题，swift的版本是1.8.0。集群由3个存储节点+一个代理节点组成，我们有2次复制。每个节点都有一个2TB的sata硬盘，操作系统运行在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
读写等待时间并不总是那么好:)，可以达到数千毫秒，这是相当可怕的。
我们还从节点端和代理中看到许多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的业务和对象过期器都停止，磁盘利用率大部分时间保持在100%。这里没有async_pending事务，但是有很多同步正在进行，可能来自对象复制器。如果所有事务都打开，则几乎在任何给定时刻都有30-50个甚至更多的async_pending事务。
我们考虑了不同的解决方案来缓解问题，这是基本的结果:
- 用于存储的ssd太贵了，所以不会发生
- 将另一个HDD与RAID0集群中的每个HDD配对(我们在swift中有复制)
- 使用一些缓存，如bcache或flashcache
你们中有人遇到过这种问题吗?有没有提示/其他地方寻找根本原因?是否有可能优化过期程序/复制程序的性能?
如果需要其他信息，请告诉我。
谢谢
我已经看到的问题，容器> 100万个对象导致超时(由于sqlite3 db无法获得锁)…你能核实你的容器的物品数吗?