OSS 性能测试经验总结

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，比如说进程切换等

通常查看网络状况的时候都是看机器网卡是否被打满，我通常用的是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不高不一定不是性能瓶颈

关于磁盘通常都是用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.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

如何对minio进行性能测试和分析 为了更好的评估minio对象存储的性能，我们需要引用一些测试工具对minio cluster进行性能分析。这里我们主要使用minio client中的speedtest还有warp作为性能分析工具。
Tablestore Adhoc 分析性能测试白皮书 本文主要介绍 Tablestore 在 Adhoc 分析场景下的性能测试，主要包括测试环境、测试工具、测试方案、测试结果以及测试结论等。
阿里云OSS上手指导（上） 随着流量渐渐起来，在图片访问这块就逐渐有压力了，毕竟现在这个年代，手机拍照的像素都是很不错的，虽然你也采用了一些常规的压缩优化手段，但在保证不丧失太多细节的情况下，一张图片的大小很容易也能达到MB吧。然而，所有的文件资源访问带宽都是由你这台主机来承担的，瓶颈会逐渐集中到带宽上。阿里云OSS提供了对象储存解决方案，我们就来了解一下。
阿里云OSS上手指导（下） OSS提供了API和SDK两种方式接入OSS，SDK提供了主流语言的实现。我们就以两种方式展开说明具体接入实现过程。
【最佳实践】OSS开源工具ossutil-上传性能调优 经常碰到内部同学或者外部客户问ossutil关于并发上传性能的问题。本文简单描述下ossutil并发上传原理并举例说明。 用户可从这里获取ossutil。 官网：https://help.aliyun.com/document_detail/50452.html代码：https://github.com/aliyun/ossutil --recursive 上传文件到oss时，如果file_url为目录，则必须指定--recursive选项，否则无需指定--recursive选项。
【OSS 排查方案-1】OSS 工具使用排查方案标准化 背景：针对使用 oss 工具出现疑问的用户，将自己经常遇到的问题解法 share 一下。 请大家在解决问题之前先做下必要的核对工作 是否是官网的最新版本 https://help.aliyun.com/document_detail/50452.html?spm=5176.doc31935.6.1056.TcGyZr。
阿里云存储服务 193985 阿里云存储基于飞天盘古2.0分布式存储系统，产品包括对象存储OSS、块存储Block Storage、共享文件存储NAS、表格存储、日志存储与分析、归档存储及混合云存储等，充分满足用户数据存储和迁移上云需求，连续三年跻身全球云存储魔力象限四强。