zoukankan      html  css  js  c++  java
  • rgw的rgw_thread_pool_size配置调整

    前言

    在比对rgw的不同前端的区别的时候,官方说civetweb是通过线程池来控制连接的,beast是后面加入了流控相关的,这块一直也没有调整过相关的参数,然后通过ab压测了一下,还是有很明显的区别的

    测试很简单,虚拟机下面就可以完成

    测试过程

    rgw_thread_pool_size = 512
    默认参数为这个

    [root@lab201 ~]# ps -ef|grep radosgw
    root      242156  239377  0 11:42 pts/1    00:00:02 tailf /var/log/ceph/ceph-client.radosgw1.log
    ceph      247068       1  3 11:53 ?        00:00:00 /usr/bin/radosgw -f --cluster ceph --name client.radosgw1 --setuser ceph --setgroup ceph
    root      247654  234613  0 11:53 pts/0    00:00:00 grep --color=auto radosgw
    [root@lab201 ~]# cat /proc/247068/status|grep Thread
    Threads:	579
    

    启动rgw进程后可以去查看这个进程的线程数目,基本接近设置值的,还有一些其它需要用的线程

    我们往s3接口里面传输一个很小的文件 260 bytes的文件,让这个文件可以公共访问,然后使用ab去并发连接这个文件,这里不是去看整个集群的负载多大,而是看下在相同的环境情况下,参数的改变会有什么区别

    ab测试

    ab -c 1000 -n 50000 http://192.168.0.201:7481/test/index.txt
    

    1000个并发请求50000次
    测试输出

    Percentage of the requests served within a certain time (ms)
      50%    180
      66%    186
      75%    193
      80%    198
      90%    214
      95%   1182
      98%   1205
      99%   2019
     100%   7589 (longest request)
    

    我们调整rgw_thread_pool_size = 128再测试一轮

    基本无法完成测试

    [root@lab204 ~]# ab -c 1000 -n 50000 http://192.168.0.201:7481/test/index.txt
    This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking 192.168.0.201 (be patient)
    Completed 5000 requests
    Completed 10000 requests
    apr_socket_recv: Connection reset by peer (104)
    Total of 14351 requests completed
    
    

    我们再加大参数配置rgw_thread_pool_size = 1024

    [root@lab204 ~]# ab -c 1000 -n 50000 http://192.168.0.201:7481/test/index.txt
    Percentage of the requests served within a certain time (ms)
      50%    281
      66%    286
      75%    290
      80%    293
      90%    299
      95%    305
      98%    310
      99%    313
     100%   1309 (longest request)
    

    可以看到与512线程的时候明显的有所改善了

    基于以上可以看到,线程如果设置小了,而外部的请求的并发连接大了,可能出现服务不响应的情况,而适当的加大线程数,也能一定程度上改善请求的效果,上面的测试仅测试验证参数的影响,而实际落地到真实环境,还需要慢慢调整

    luminous版本的beast也是需要调整上面的线程池的参数来应对超多连接的情况的,否则客户端很容易就异常了

    客户端并发请求最大值调整

    [root@lab204 ~]# ab -c 3000 -n 50000 http://192.168.0.201:7481/test/index.txt
    This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/
    
    Benchmarking 192.168.0.201 (be patient)
    socket: Too many open files (24)
    

    默认的为1024,需要调整下参数

    [root@lab204 ~]# ulimit -n 4096
    

    调整后就可以加大并发请求了

    变更记录

    Why Who When
    创建 武汉-运维-磨渣 2020-09-11
  • 相关阅读:
    #敏捷个人# 每日成长101:第72天【自我接纳】
    如何从敏捷个人架构图看出时间管理的演变
    #敏捷个人# 每日成长101:第73天【选择】
    2012年度总结:内心宁静的2012
    欢迎关注敏捷个人微信公众帐号
    敏捷个人的创立与详解Scrum会议
    学习敏捷个人卡片V1.0
    #敏捷个人# 每日认识101(11):做自己的医生
    #敏捷个人# 面向对象分析与PPT有什么关系?
    《敏捷个人-认识自我,管理自我 v0.6.pdf》配套PPT打印书籍
  • 原文地址:https://www.cnblogs.com/zphj1987/p/13650943.html
Copyright © 2011-2022 走看看