关于gfs超时问题总结

1.glusterfscup占用率过高

    高峰期glusterfs的cpu占用率达到280%(top指令查看),并且通过验证在cpu高的时候就会有超时出现;

  首先判断是sys还是usr比较占cpu,通过dstat查看是系统比较占cpu(mpstat也可以查看),这说明是内核态有过多的操作,问题在内核不在glusterfs代码本身;

   通过perf指令查询,发现_spin_lock_irq这个内核函数占用时间较长,例子如下(具体参见perf_result_glusterfsd_128136.txt文档):

[root@bj-nx-cip-w87 ~]# perf record  -g -p 128136(glusterfs进程对应IP)

^C[ perf record: Woken up 28 times to write data ]

[ perf record: Captured and wrote 7.178 MB perf.data (~313619samples) ]

[root@bj-nx-cip-w87 ~]# perf report --stdio

# Events: 47K cycles

#

# Overhead    Command          Shared Object                                  Symbol

# ........  .........  .....................  ......................................

#

    91.51%  glusterfs [kernel.kallsyms]      [k]_spin_lock_irq

            |

            --- _spin_lock_irq

               |         

               |--99.64%--compact_zone

               |          compact_zone_order

               |          try_to_compact_pages

               |          __alloc_pages_nodemask

               |          alloc_pages_vma

               |          do_huge_pmd_anonymous_page

               |          handle_mm_fault

               |          __do_page_fault

               |          do_page_fault

               |          page_fault

               |          |         

               |          |--94.45%-- xdr_callmsg_internal

               |          |          0x3829b98860

               |          |         

               |           --5.55%-- __memcpy_sse2

                --0.36%--[...]

在_spin_lock_irq这个内核函数里compact_zone这个函数花费时间最长

 查看网络相关资料:http://blog.csdn.net/lin_fs/article/details/9146971

 内存碎片整合的时候耗费了大量cup的时间;文章里面提到了THP(即Transparenthugepages)

 搜索Transparenthugepages相关内容得文章:http://blog.csdn.net/lin_fs/article/details/9146213

正好符合我们当时线上的情况;

执行指令:echo never >/sys/kernel/mm/redhat_transparent_hugepage/defrag

Cpu有所下降;

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled  这个写到/etc/rc.local  防止其开机后失效;

关于TransparentHugepage的相关资料:http://blog.csdn.net/lin_fs/article/details/9146273

 

2.压力下Glusterfscpu占用过高和xdr_callmsg (&xdr, request)这个函数耗时的关系

     Xdr_callmsg不是内核函数而是libc里面的一个函数,在这个函数里面申请了内存(参见rpc_callmsg.c)触发了Transparent Hugepage进行碎片整理,所以导致glusterfs的cpu占用过高;(为什么会触发Transparent Hugepage?Transparent Hugepage有什么作用)

总结:

1.压力过大只是一个表象,任何系统都是可以优化的;

2.找到根本性原因才能找到根本性的措施

3.相关定位问题工具:dstat, mpstat, perf, strace, pstack

3.后期的维护

     一个分布式文件系统的性能问题,往往会受到这个文件系统所在的服务器的本地文件系统(ext4)和内核(CnetOS)的一些bug的影响。调整好好这些参数,对这个集群的性能都会有很大的改善。

    后期维护参考资料:http://blog.csdn.net/peter_cloud/article/details/9139111

你可能感兴趣的:(关于gfs超时问题总结)