求助 nginx作为图片服务器 disk io 很高

fanngyuan

各位：

我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

wgm.china

你好！

我也有类式的项目，我想应该是你的nginx打开IO很多，我建议你看看所有打开的文件是否有很多重复文件，如果是重复文件打开较多的话，可以采用nginx cache优化一下。

我的nginx设置是这样的：

1，80 接收到请求后proxy_pass http://127.0.0.1:8080/,打开nginx_cache配置，这样可以利用一些nginx_cache，优化一些重复文件的性能，我这样后效果非常好。

2，打开sendfile 对性能会比较好。

在 2013-11-19，下午9:16，fanng yuan <fann...@gmail.com> 写道：

各位：
我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

--

yaoweibin

On 2013/11/19 21:16, fanng yuan wrote:
> 閿熸枻鎷蜂綅閿熸枻鎷?> 閿熸枻鎷烽敓鏂ゆ嫹浣块敓鏂ゆ嫹nginx閿熸枻鎷蜂负鍥剧墖閿熸枻鎷烽敓浠婏紝鍑ゆ嫹閿熸枻鎷穒o鍗犻敓鐭緢楂橈綇鎷穒ostat閿熸枻鎷烽敓鏂ゆ嫹io鍗犻敓鐭》鎷烽敓鏂ゆ嫹閿熸枻鎷?> 100%閿熸枻鎷穒otop閿熸枻鎷烽敓鐨嗗尅鎷烽敓鏂ゆ嫹閿熸枻鎷穘ginx閿熸枻鎷穡orker閿熸枻鎷峰崰閿熸枻鎷稩O 閿熸枻鎷烽敓渚ユ枻鎷疯箣閿熼叺?閿熸枻鎷穕sof閿熸枻鎷烽敓浠嬬湅
> 閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷锋獉铓?纰夋嫹鍥剧墖閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷峰嵈閿熻璇ф嫹閿熻寰堝锛岄敓瑗熼儴鍒嗕紮鎷烽敓鏂ゆ嫹http閿熸枻鎷烽敓鎺モ槄鎷烽敓鏂ゆ嫹閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷?> 閿熻В锛岄敓鏂ゆ嫹閿熻剼浼欐嫹閿熸枻鎷烽敓鏂ゆ嫹瀹為敓鏂ゆ嫹娌℃

fanngyuan

sendfile，已经打开了，cache我再另一台机器上打开了

2013/11/19 wgm <wgm....@gmail.com>

你好！
我也有类式的项目，我想应该是你的nginx打开IO很多，我建议你看看所有打开的文件是否有很多重复文件，如果是重复文件打开较多的话，可以采用nginx cache优化一下。

我的nginx设置是这样的：
1，80 接收到请求后proxy_pass http://127.0.0.1:8080/,打开nginx_cache配置，这样可以利用一些nginx_cache，优化一些重复文件的性能，我这样后效果非常好。

2，打开sendfile 对性能会比较好。

在 2013-11-19，下午9:16，fanng yuan <fann...@gmail.com> 写道：

各位：
我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

--
class="HOEnZb">

--

agentzh

Hello!

2013/11/19 fanng yuan:
> 我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。
>

建议直接测试你的 IO 等东西对 nginx worker 进程的阻塞效应。如果你是在 Linux 系统上，可以使用下面这几个工具：

* sample-bt-off-cpu 工具可以用于绘制 off-CPU 时间火焰图：

    https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-off-cpu

* sample-bt-vfs 工具可测量虚拟文件系统层面上的读写 IO 火焰图（包括延时和数据量等多个维度）：

    https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-vfs

* epoll-loop-blocking-distr 可用于测量 epoll 事件循环被阻塞的延时分布：

    https://github.com/agentzh/stapxx#epoll-loop-blocking-distr

* ngx-req-latency-distr 工具可用于测量请求的处理延时分布：

    https://github.com/agentzh/stapxx#ngx-req-latency-distr

当然，你在 Nginx Systemtap Toolkit 和 Stap++ 这两个项目中还可以找到许多其他有用的工具。

Best regards,
-agentzh

fanngyuan

谢谢春哥，我试试

2013/11/20 Yichun Zhang (agentzh) <age...@gmail.com>

Hello!

2013/11/19 fanng yuan:

> 我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。
>

建议直接测试你的 IO 等东西对 nginx worker 进程的阻塞效应。如果你是在 Linux 系统上，可以使用下面这几个工具：

* sample-bt-off-cpu 工具可以用于绘制 off-CPU 时间火焰图：

https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-off-cpu

* sample-bt-vfs 工具可测量虚拟文件系统层面上的读写 IO 火焰图（包括延时和数据量等多个维度）：

https://github.com/agentzh/nginx-systemtap-toolkit#sample-bt-vfs

* epoll-loop-blocking-distr 可用于测量 epoll 事件循环被阻塞的延时分布：

https://github.com/agentzh/stapxx#epoll-loop-blocking-distr

* ngx-req-latency-distr 工具可用于测量请求的处理延时分布：

https://github.com/agentzh/stapxx#ngx-req-latency-distr

当然，你在 Nginx Systemtap Toolkit 和 Stap++ 这两个项目中还可以找到许多其他有用的工具。

Best regards,
-agentzh

--

miaohonghit

cache很重要，我之前io也高，现在正在用春哥的share.DICT做一个文件头信息缓存，希望可以降io

你也可以试试

在 2013年11月19日下午9:16，fanng yuan <fann...@gmail.com>写道：

各位：
我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

--

--

Best Regards,
Harold Miao

wgm.china

文件头信息缓存是什么意思？谢谢给我一个大概的思路。

在 2013-11-20，上午11:58，"Harold.Miao" <miaoh...@gmail.com> 写道：

cache很重要，我之前io也高，现在正在用春哥的share.DICT做一个文件头信息缓存，希望可以降io

你也可以试试

在 2013年11月19日下午9:16，fanng yuan <fann...@gmail.com>写道：

各位：
我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

--

--

Best Regards,
Harold Miao

--

miaohonghit

sorry, 我说的可能有歧义。其实是针对我们独特的需求的，我们是将大文件切割然后压缩，这样就会有个头指明每个分段的位置大小等。

业务场景不同，可能理解有偏差

在 2013年11月20日下午12:13，wgm <wgm....@gmail.com>写道：

文件头信息缓存是什么意思？谢谢给我一个大概的思路。

在 2013-11-20，上午11:58，"Harold.Miao" <miaoh...@gmail.com> 写道：

cache很重要，我之前io也高，现在正在用春哥的share.DICT做一个文件头信息缓存，希望可以降io

你也可以试试

在 2013年11月19日下午9:16，fanng yuan <fann...@gmail.com>写道：

各位：
我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

--

--

Best Regards,
Harold Miao

--

--

--

Best Regards,
Harold Miao

wgm.china

o,知道了，我们也有这样的场景，不过我们是做到数据库中，前面再加上share.dict。

在 2013-11-20，下午12:39，"Harold.Miao" <miaoh...@gmail.com> 写道：

sorry, 我说的可能有歧义。其实是针对我们独特的需求的，我们是将大文件切割然后压缩，这样就会有个头指明每个分段的位置大小等。

业务场景不同，可能理解有偏差

在 2013年11月20日下午12:13，wgm <wgm....@gmail.com>写道：

文件头信息缓存是什么意思？谢谢给我一个大概的思路。

在 2013-11-20，上午11:58，"Harold.Miao" <miaoh...@gmail.com> 写道：

cache很重要，我之前io也高，现在正在用春哥的share.DICT做一个文件头信息缓存，希望可以降io

你也可以试试

在 2013年11月19日下午9:16，fanng yuan <fann...@gmail.com>写道：

各位：
我们使用nginx作为图片服务，发现io占用很高，iostat发现io占用几乎是100%，iotop可以看到，nginx的worker是占用IO最多的进程，通过lsof来查看单个进程打开的图片数量，却又不是很多，大部分还是http链接。如何诊断问题，并优化，我实在没思路了，请教各位高手。

--

--

Best Regards,
Harold Miao

--

--

--

Best Regards,
Harold Miao

--