mirrors 启用 SSD cache

优化之前,mirrors 磁盘阵列(sdh)的 io util 常常在 90% 以上,有些时候甚至“稳定”在 100%。从sda 往 sdh 复制一些小文件,竟然不到 5MB/s。尝试调整了 iscsi 的 MTU、txqueuelen 等网络参数,没有效果,瓶颈可能不在网络上。以一块 7500rpm SATA 磁盘随机读 75~100 iops 计算,RAID6 的 iops 大约是 450~600 iops,与我们的测试结果基本相符,因此磁盘阵列可能本来就这么慢。

SSD(/dev/sdb)被格式化为 ext4 文件系统(UUID=8e19059d-358e-41ca-8896-b9b26a2d4f59),用 tune2fs 去掉了 journal。挂载参数为 nodev,nosuid,noatime,discard,挂载点为 /mnt/ssd。

用 fio 测试结果如下(使用 1G 文件):

  • 连续读 139327KB/s,34831 iops
  • 连续写 1001.1MB/s,256500 iops
  • 同时连续读写,与单独测试相比没有明显变化
  • 随机读 15708KB/s,3926 iops
  • 随机写 762047KB/s,190511 iops
  • 同时随机读写,与单独测试相比没有明显变化

写的性能这么好,估计是由于 buffer。连续读性能不高,是因为 SSD 在 RAID 卡后面,不过对我们来说足够了。我们最关心的随机读性能 3926 iops 达到了预期,目前磁盘阵列的随机读性能不到 500 iops。

SSD cache 的缓存策略基于 HTTP access log。每天凌晨,选出前一周的 HTTP 200 请求,按照 URL 访问频率降序排序,填满 SSD cache 为止。

注册登录 USTC LUG GitLab,即可查看源代码:https://gitgeek.net/mirrors/ssd-cache

cron-cache.sh 每天运行一次,生成缓存:

  1. 读出最近7天的 HTTP access log
  2. 取出 200 请求,统计 URL 访问频率
  3. 筛选至少访问过2次的文件,按频率降序排序,得到 filefreq-20131010.gz 这样的文件列表。
  4. 从上述文件列表中依次取出文件,获取其大小,添加到缓存列表(tocache-20131010)中,直到达到设定的缓存总大小。
  5. 用 rsync 把缓存列表中的文件同步到缓存区。用 rsync 的好处是文件没有被修改时不需要重新复制,由于多数文件的访问频率是相对稳定的,每天复制的数据量并不大。

每个源同步后,要刷新 cache,这是 update-cache.sh 的职责。它同样使用了 rsync。

200G 的缓存共缓存了 3696 个文件(其中 iso 文件占 422 个),根据前7天的 HTTP 200 日志,最多的在7天内被访问了 1036142 次,最少的在7天内被访问了 97 次。

SSD cache 的效果怎么样呢?200G 的 cache 同步完成后,

  • 磁盘阵列(sdh)的负载从一直 90%+,降到了时而 90%+,时而 50%~60%
  • 总流量增加了约 50Mbps(原来是 ~350 Mbps,后来是 ~400 Mbps)
  • load average 似乎没有明显变化
  • 被缓存文件的校内下载速度可达 50~70 MB/s,能够吃满 mirrors 的千兆网卡

希望 status.lug.ustc.edu.cn 和 mirrors 的 collectd-web 尽快恢复,以便对 SSD 的效果做更多更直观的观察和评估。

freeshell 升级到千兆带宽接入

今天修改了少年班学院的网络拓扑,freeshell 等服务器的 IPv4 接入校园网速度从百兆升级到了千兆。需要注意的是,您访问 freeshell 服务器的速度达到 50MB/s 就不错了,因为网络速度还取决于您的网络接入速度(例如,很多机房和实验室都是百兆接入)和校园骨干网络的拥塞程度。

IPv6 由于走的是另一条线路,仍然是百兆。

Freeshell 控制面板修复状态显示

从10月3日 blog 服务器添加移动线路 IP 地址,freeshell 控制面板就不能正常显示 freeshell 的状态。原因是 freeshell 所在 blog 服务器的默认出站IP变成了 202.141.176.99,控制面板与虚拟机节点是通过 ssh 通信的。而虚拟机节点上的 authorized_keys 上限制了连接IP为 202.141.160.99,因此 ssh 连接被拒绝。

把到校内网络的默认路由改成 202.141.160.99 的线路后,问题解决。感谢 崔灏 同学的问题报告。

Gitlab的bug修复

gitlab升级到6.0之后,用户在新建project选择namespace的时候,会发现无法选择以前创建的group。这个bug推测是升级的时候造成的。

原因是在users_groups这个表中无法找到这些组的信息。

$ mysql -u root -p

$ use gitlab;

$ show tables;

users_groups表存储了用户和group的关系,其中的group_access推测是权限,50是指group owner。

namespaces表储存了namespace。这里的id就是users_groups表中的group_id。

将丢失的信息重新加进去就可以了

GitLab 支持 SPDY 协议

GitLab 支持 Google 提出的 SPDY 协议,通过压缩、多路复用,可以有效加速 HTTPS 协议。我们使用了 Nginx 1.4 开始内置的 SPDY 模块,支持 SPDY/2 协议。

赶快来体验 SPDY-enabled 的 gitgeek.net 吧!

  1. 用 Chrome 浏览器,先访问 https://gitgeek.net/users/sign_in 再访问 chrome://net-internals/#spdy 看 gitgeek.net 是否在 SPDY Sessions 列表中。
  2. 使用第三方 SDPY 协议验证工具:http://spdycheck.org/#gitgeek.net

To GitLab Maintainers: SPDY 需要 Nginx 1.4+ 和 OpenSSL 1.0.1c+,Nginx 1.5.6 是从官网上下载源码编译的,OpenSSL 1.0.1e 是加入了 Debian sid 源后升级的(原来是 OpenSSL 0.9.8)。OpenSSL 1.0.1e 又依赖 gcc 4.5+,而 Debian squeeze 上的 gcc 是 4.4.x,因此把 gcc 也升级到了 4.8,libc 也升级到了 2.17。不要随意执行 apt-get upgrade 了,以免把整个系统升级到 sid。

Freeshell 修复访问校外网络

早先 Freeshell 节点上配置的 NAT 是写死的 IPv4 地址,因此与 blog 服务器之间的 OpenVPN 连接断开重连之后,IP 地址一改变,NAT 就不能工作了。因此前些天重启 blog 上的 OpenVPN 服务后 Freeshell 的外网连接就一直不可用。

现在改成了 MASQUERADE 模式,不论 IP 地址怎么变,NAT 都能工作。初步测试各 freeshell 节点的外网连接恢复。

BTW,LUG VPN IPv4 出国会自动选择合适的路线。大家可以用 curl -4 -vv googleblog.blogspot.com 测试。注意,IPv6 可能被 connection reset。对某些不存在的站点,DNS 是错误的,请手动设置 8.8.8.8 作为 DNS。

lug.ustc.edu.cn 临时切换到 blog 服务器

由于 lug 服务器发生严重故障,且这几天是十一假期,无法进入机房修复,我们把 lug.ustc.edu.cn 的 DNS 临时切换到 blog 服务器。原来的 LUG 服务器可以通过 ftp.lug.ustc.edu.cn 访问。

目前 lug.ustc.edu.cn 只提供 wiki 服务,即 LUG 主页运行正常。ServMon 监控服务也已经转移。未恢复的服务包括:

  • LUG FTP
  • LUG TimeMachine
  • Ganglia 服务监控 status.lug.ustc.edu.cn

上述服务需要等 lug 服务器恢复,非常抱歉。LUG 服务器上的一些其他服务,包括 {php,roundup}.lug.ustc.edu.cn 均无法使用。

Blog 服务器添加移动线路

重启成功,所有服务自动启动,服务中断时间在2分钟以内。

blog.ustc.edu.cn 和 freeshell.ustc.edu.cn 都添加了 202.141.176.99 这个移动线路的IP。目前设置电信线路、教育网解析到原来的 202.141.160.99 电信IP,其余(包括但不限于移动、联通、国外)解析到新加的移动IP。预计 blog 在国外的访问速度将有明显改善。

Blog 服务器还储备了 202.141.176.112 和 202.141.176.113 两个移动IP,可用于其他不共享 SSL 证书的站点。