OSS 性能测试经验总结-阿里云开发者社区

开发者社区> 阿里云存储服务> 正文

OSS 性能测试经验总结

简介:

OSS 性能测试经验总结

1、CPU 相关

1.1 进程使用CPU

我们通常都会习惯性的用top 去查看进程CPU 使用率,但是通常会进入以下误区

系统CPU idle很高CPU不是性能瓶颈

通常我们在看进程CPU使用率的时候用的是top,默认是按照CPU使用排序的,而且这时候看到的进程CPU使用情况是整个进程的,进程内部所有线程CPU使用的总和,这时候如果要进一步确定CPU不是性能瓶颈就要进一步查看进程内每个线程CPU使用情况:
top -H -p pid
这时候会将进程内所有线程按照CPU使用情况排序列出来,这时候观察CPU使用情况,这时候如果有进程CPU使用率持续在90% 或者100% 说明CPU就有可能是瓶颈了。
比如说一个web服务器在设计的时候由一个进程专门进行accept 新的连接,连接完成后交由其他进程处理,此时如果该进程用满单核CPU就会造成性能瓶颈。这时候可以进一步确认将CPU 用满的进程在干啥,是否在进行符合我们预期的操作:
pstack pid

案例

在Nginx multi_accept on; 这一项打开后,在压力极大的情况下,每一秒有3W+的tcp连接请求过来Nginx 某个worker 每时每刻都会有新的连接需要建立,导致这个worker 一直hold 住accept互斥锁不释放, 造成Nginx 严重负载不均,这个worker 一直在accept 新的连接被打满(满占一个CPU),而其他worker闲着没事做, multi_accept 项关闭后解决。 pstack 看这个worker 一直在accept 新的连接。

1.2 软中断使用CPU

系统上每时每刻都会有很多软中断产生,这些软中断会悄无声息的使用CPU,而通常由硬件产生的软中断对CPU具有亲和性,比如说中断号为100的中断对CPU0 有亲和性,如果某个时候100 号软中断非常多就会造成CPU0被打满,处理不了更多中断造成性能瓶颈。这时候可以用以下命令查看下单个CPU的使用率:
top +1 (输入top命令后按1)有可能CPU核心太多屏幕太小显示不出来,尝试用下面命令
mpstat -P ALL 1
具体案例下面的网络部分。

1.3 总结

a、系统CPU idle 很高CPU不一定不是性能瓶颈,有可能单个进程吃满单核CPU
b、系统CPU idle 很高也没发现有单个进程吃满单核CPU情况下CPU不一定不是瓶颈,有可能单核CPU被打满,因CPU亲和性问题造成性能瓶颈

注:当然还有很多其他情况会使用CPU,比如说进程切换等

2、网络

通常查看网络状况的时候都是看机器网卡是否被打满,我通常用的是ifstat 或者dstat 来看, 但是也会有以下误区

网卡未打满网络就不是瓶颈

2.1 大量小包情况下

这种情况比较好理解,假设用http 短连接上传到OSS数据,每个Object 1字节,从抓包上看一次PUT 操作要产生八个包TCP 三次握手,四次挥手加上一次1字节数据传输,光进行这一个字节数据的传输就要产生8个tcp 报文,底层网卡怎么滴也会产生8次中断吧。不过这种场景只有在很极端的情况下才会出现,而且通常都是后端Server 先到达性能瓶颈。

2.2 上游网络环境差丢包严重导致

这种情况也比较好理解,因为现在基本上网络通信用的都是TCP,如果上游网络环境差会造成丢包现象出现,丢包会触发TCP协议的拥塞控制算法,进而导致整体网络使用率上不去,这里可以使用tsar 工具查看系统丢包率 tsar --live, 注意观察retran 一项。但有时候系统丢包率高有可能并不是上游网络环境差造成,具体见2.3 分析。

2.3 网卡软中断打满单核CPU造成性能瓶颈

2.3.1 现象及原因

这种情况比较常见,尤其是在万兆网的机器上,网络流量达到1GB 也算是比较轻松的事情,但是经常会有这种情况出现,万兆网机器,网络流量打到400M的时候就再也打不上去了,利用淘宝对外提供的开源监控工具tsar 查看下系统丢包率,如果有异常有可能是2.2 描述的原因,但是也有可能是自身原因。
分析步骤:
1、查看系统CPU使用情况

mpstat -P ALL 1  
top +1

注意观察是否出现某个CPU被软中断打满的情况,如下图:

如果出现如下情况说明是网卡软中断对CPU0有亲和性,需要对网卡软中断进行分流了。

2.3.2 网卡软中断打满单核CPU造成的影响

网卡打满单核CPU情况造成的影响很多很坏而且不好查,首先我们知道网卡一定是有自己的buffer的,如果网卡产生的软中断没有被及时处理,就会导致网卡buffer溢出,直接导致的后果就是丢包,丢包会触发TCP拥塞控制导致网卡使用率上不去。

2.3.3 如何判断网卡软中断是否分流及如何设置

当前一般千兆网或者万兆网都是多队列网卡,网卡产生的软中断会对于到多个中断号,查看多队列网卡对应的中断号:
cat /proc/interrupts | grep eth | awk '{print $1 " " $NF}'

vim 打开 /proc/interrupts 查看软中断是否都落在同一个CPU上
更精确的查看方法是看 /proc/irq/$interupt_id/smp_affinity, 里面会有一串十六进制数字
具体含义和设置方法不做过多介绍,详见:http://blog.csdn.net/turkeyzhou/article/details/7528182

2.4 总结

a、丢包严重不一定是上游网络问题
b、网卡util不高不一定不是性能瓶颈

3、磁盘

关于磁盘通常都是用iostat 去看磁盘使用情况,但是也有问题,也会进入误区

3.1 关于磁盘使用率(IOPS争抢)

通常我们在查看磁盘使用率的时候都会用iostat 去看,我比较常用的是如下命令:
iostat -x 1
最后一项有个磁盘util 项,千万不要被这个值迷惑,这个值只是磁盘在1s 内的平均使用率
有可能在1s内的某个瞬间磁盘使用率达到100% 到达性能瓶颈。

3.2 因IOPS 争抢丢日志案例

在机器压力比较大的时候发现Nginx 和我们的后端Server 都有不同程度的丢日志现象,Nginx 日志和我们后端Server日志都是打在同一块盘上的,于是开始怀疑是磁盘IOPS被打满导致,想当然的用iostat -x 1 查看磁盘使用率,看到这块盘在1s 内有util 可以达到80%,但是没有看到100%的情况,因此开始怀疑有可能在1s 内磁盘使用率达到100%,为了证实我的想法将Nginx 日志和后端Server 日志分别达到不同磁盘上,再用iostat 去观察,发现两块盘都有使用率到80%的情况,加起来超过100%,因此确定打在一块盘上确实是会造成IOPS争抢导致丢日志。

3.3 总结

a、一段时间内磁盘使用率低不代表瞬时使用率也低

4、内存

关于了内存这块,测试过程中很少出现因内存问题造成性能瓶颈,所以没太多经验,不过还是有一点需要强调下

4.1 关于可用内存

是否是内存free 的越少表面内存就越不够用?不是这样的,free 内存越少只能证明Linux 对内存使用率越高,通常系统可用内存分为三块,一块是free 部分,一块是读Cache 部分,还有写buffer,Cache通常指的是读Cache(Linux 会利用多余的主存来做读Cache,也就是传说中的Page Cache)。

chy@ubuntu:~$ free -m
                     total       used       free     shared    buffers     cached
        Mem:          4024       2507       1516          0        237       1170
        -/+ buffers/cache:       1100       2924
        Swap:         1021          0       1021

可以看到下一行-/+ buffers/cache,我理解这里的free 才是真正的使用可用内存,当free 量不够之后系统清先清Cache 和 buffer 使用的内存供进程使用,等这些都用完了才会考虑swap。

4.2 总结

a、free 内存少不代表系统内存不够用

附录

使用到的命令

top 
top -H -p pid
top +1
pstack pid
tsar --live
ifstat
 dstat
mpstat -P ALL 1
iostat
iostat -x 1

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

阿里云存储基于飞天盘古2.0分布式存储系统,产品多种多样,充分满足用户数据存储和迁移上云需求。

官方博客
链接