关于gfs超时问题总结

1.glusterfs的cup占用率过高

    高峰期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.压力下Glusterfs的cpu占用过高和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