免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: tomtesla

[Web] 如何配置高并发linux服务器 [复制链接]

论坛徽章:
0
发表于 2014-03-25 12:20 |显示全部楼层
关注ing

并发性能我觉的还要关注一下应用,比如说达到10万并发,是什么应用或者场景下,对于Web访问来说,如果不涉及数据库,不涉及或甚少磁盘IO,找个好一些的服务器达到这个我觉得不是难事,但如果涉及上述因素,10万并发就太难了。 想想银行用的什么机器吧,也不见得就能达到10万并发。

论坛徽章:
1
2015年辞旧岁徽章
日期:2015-03-03 16:54:15
发表于 2014-03-25 14:32 来自手机 |显示全部楼层
我只理论讨论下,内存是个第一因素,因为内存跟cpu,磁盘io,网卡缓存,web代码算法,数据库执行计划算法都有关。所以web服务器和数据库最好分开在不同机器上进行测试。

论坛徽章:
7
CU大牛徽章
日期:2013-03-14 14:16:29CU大牛徽章
日期:2013-03-14 14:16:32CU大牛徽章
日期:2013-03-14 14:16:34CU大牛徽章
日期:2013-03-14 14:16:35IT运维版块每日发帖之星
日期:2015-07-13 23:09:32IT运维版块每日发帖之星
日期:2015-07-13 22:20:00数据库技术版块每日发帖之星
日期:2015-09-08 06:20:00
发表于 2014-03-25 16:37 |显示全部楼层
这种情况就不要在虚拟机上试了,用真机吧

论坛徽章:
0
发表于 2014-03-27 09:38 |显示全部楼层
回复 19# liyong_nb

"瓶颈在网卡,"?  

   这个我不赞同,即便在本机压测,网卡流量也从来没有到达过任何限制,之前局域网G口 压测,也是这个样子,已经确认与网卡流量限制无关。

论坛徽章:
0
发表于 2014-03-27 09:44 |显示全部楼层
回复 21# bellman


嗯,现在的问题就是我想用压测工具重现10万并发,并且研究一下如何达到这个并发值,以及什么样的server 系统配置可以支撑 纯helloworld的 10万并发, 你说的有道理,银行的server 实际业务请求够呛达到10万并发, 估计连12306的订票系统,核心业务也很难达到这个数值,否则12306就不那么容易挂掉了。


我发这个帖子的目的就是,难道非得在我根本拿不到的特殊配置的机器小型机 服务器上才能达到我想要的并发值?  目前我能测试的,单核vps,虚拟机 到 24核32G物理机 都有,但是还没有发现达到 高并发的瓶颈所在。 希望高手指点!

   

论坛徽章:
0
发表于 2014-03-27 09:46 |显示全部楼层
sohusina 发表于 2014-03-25 14:32
我只理论讨论下,内存是个第一因素,因为内存跟cpu,磁盘io,网卡缓存,web代码算法,数据库执行计划算法都 ...



注意看一下前面的压测结果, 我们仅仅压测“helloworld”  不涉及任何web 业务代码,数据库并发。

论坛徽章:
0
发表于 2014-03-27 09:47 |显示全部楼层
wangyb 发表于 2014-03-25 16:37
这种情况就不要在虚拟机上试了,用真机吧


已经试过多台了  您要是有兴趣,麻烦也在真机上测试一下

论坛徽章:
218
2022北京冬奥会纪念版徽章
日期:2015-08-10 16:30:3215-16赛季CBA联赛之上海
日期:2019-09-20 12:29:32操作系统版块每日发帖之星
日期:2016-03-02 06:20:00操作系统版块每日发帖之星
日期:2016-03-01 06:20:00操作系统版块每日发帖之星
日期:2016-02-18 06:20:00操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-05-10 19:22:58月度论坛发贴之星
日期:2016-01-31 22:25:02操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-05-10 19:22:58操作系统版块每日发帖之星
日期:2016-05-10 19:22:58
发表于 2014-04-05 13:19 |显示全部楼层
本帖最后由 action08 于 2014-04-09 08:15 编辑

回复 22# sohusina


    仅谈nginx的响应敏捷程度,貌似还是跟cpu情况有关吧
  1. root@mh3:~# curl localhost/
  2. <html>
  3. <head>
  4. <title>Welcome to nginx!</title>
  5. </head>
  6. <body bgcolor="white" text="black">
  7. <center><h1>Welcome to nginx!</h1></center>
  8. </body>
  9. </html>
  10. root@mh3:~#
复制代码
ab -c 100 -n 100000 localhost/情况下,就内存前后变化差距也就几兆吧

论坛徽章:
0
发表于 2014-04-09 17:17 |显示全部楼层
回复 28# action08

首先感谢chinaunix将本技术讨论帖置成了“精华”,希望更多高手指点迷津。


ab 压测本机 时 内存变化确实不大,可以猜测与cpu有关,但是跟cpu的主频有关还是cpu核数有关呢?

而且排除掉 ab压测本机时ab自身占用的cpu,比如跑在24核主频3.30GHz 上,cpu表示毫无压力,但是压测结果并没有表现出大的跳跃,这是为何?


由于本着实验科学的精神,调整系统参数,编译nginx,在多台机器测试,对比压测结果的情况下,最近转向到重新编译系统内核, 不知是否可解?

有同仁可以ab压测10万并发的,麻烦贴一下截图,感激涕零 :)

论坛徽章:
11
技术图书徽章
日期:2014-03-01 14:44:34天蝎座
日期:2014-05-21 22:11:59金牛座
日期:2014-05-30 17:06:14
发表于 2014-04-12 20:13 |显示全部楼层
回复 29# tomtesla

楼主的精神值得肯定,不过我觉得进入误区了。

首先。淘宝的实验是nginx维持2M HTTP长连接不断,无需返回数据,需要开发一个nginx module,而不是你理解的每秒接入2M个HTTP短连接的同时还要回传静态文件!前者有一台牛X服务器和调整内核TCP参数就搞定了,后者得用服务器集群才能完成。文章链接http://ehealth-aussie.blogspot.c ... of-nginx-for-2.htmlhttp://www.itzk.com/thread-583354-52-1.shtml

其次。要考虑ab本身的性能问题,因为TCP有流控,ab性能不行,也会拖累nginx回包和关闭链接的延迟,最终就影响整体并发,尝试同时开多个ab发包。

最后。改进方向可以从网络中断处理入手。并附上我PC虚拟机测试结果(fedora 20, 四核2.3GHz,  2GB内存)

内核参数调整:
  1. $ echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
  2. $ echo 1024 > /proc/sys/net/core/somaxconn
复制代码
nginx配置:
  1. worker_processes  1;
  2. worker_rlimit_nofile 81920;
  3. events {
  4.     multi_accept on;
  5.     worker_connections  8192;
  6. }
复制代码
启动两个ab
  1. $ (ab -c 100 -n 100000 http://10.211.55.5:8080/ &) && ab -c 100 -n 100000 http://10.211.55.5:8080/
复制代码
统计access.log看总请求数,能稳定在每秒28K:
  1. [root@localhost nginx]# tail -200000 access.log | awk '{ print $4 }' | sort | uniq -c
  2.   22401 [12/Apr/2014:19:05:57
  3.   27752 [12/Apr/2014:19:05:58
  4.   28119 [12/Apr/2014:19:05:59
  5.   28301 [12/Apr/2014:19:06:00
  6.   28291 [12/Apr/2014:19:06:01
  7.   28424 [12/Apr/2014:19:06:02
  8.   27378 [12/Apr/2014:19:06:03
  9.    9334 [12/Apr/2014:19:06:04
复制代码
网络中断处理,一个worker,两个ab,不过中断处理占用大量系统CPU而且只压一个core,也试了更多的worker或ab,性能甚至会下降。
当前单worker的性能接近极限了,strace统计下上述过程系统调用延时,虽然attach后进程整体效率下降很大,但系统调用的统计还是比较准确:
  1. [root@localhost nginx]# strace -cT -tt -p 3158 -o strace.sum.$(date '+%H%M%S').log

  2. [root@localhost nginx]# more strace.sum.193623.log
  3. % time     seconds  usecs/call     calls    errors syscall
  4. ------ ----------- ----------- --------- --------- ----------------
  5. 12.67    0.366589           4    100000           writev
  6. 12.38    0.358369           2    200000           close
  7. 12.36    0.357587           4    100000           sendfile64
  8. 11.73    0.339572           2    200223       223 recv
  9. 10.79    0.312281           3    100000           shutdown
  10.   7.60    0.220087           2    101000      1000 accept4
  11.   7.13    0.206290           2    100000           epoll_ctl
  12.   7.03    0.203432           2    100000           write
  13.   6.41    0.185492           2    100000           open
  14.   6.35    0.183873           2    100000           stat64
  15.   5.21    0.150814           2    100000           fstat64
  16.   0.21    0.005944           3      2000           epoll_wait
  17.   0.13    0.003857           2      2001           gettimeofday
  18. ------ ----------- ----------- --------- --------- ----------------
  19. 100.00    2.894187               1305224      1223 total
复制代码
理顺上面的表格逻辑,可能还要单独strace一次nginx worker的处理流程。总之一次请求处理仅系统调用占用接近30us,加上少量用户CPU和进程上下文切换,每秒处理极限就在30k左右。vmstat查看,系统CPU时间占绝对多数,系统(网络)中断和上下文切换比较高,在虚拟机下也很难改善了。
  1. bash-4.2 $vmstat 3
  2. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  3. r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  4. 4  0      0 1021204  27220 884724    0    0     2     9  117  165  0  2 98  0
  5. 4  0      0 1009984  27220 892592    0    0     0     0 5661 2000  3 34 63  0
  6. 3  0      0 999672  27228 900604    0    0     0     4 5644 1975  3 34 63  0
  7. 3  0      0 989224  27228 908496    0    0     0     0 5608 1826  3 34 63  0
  8. 3  0      0 979460  27236 916464    0    0     0 13200 5598 1812  3 34 62  0
  9. 3  0      0 969080  27248 924144    0    0     0  4433 5728 2105  3 34 62  0
  10. 3  0      0 958652  27248 932280    0    0     0     0 5606 1905  3 34 63  0
  11. 3  0      0 946404  27256 940240    0    0     0     9 5734 2074  4 33 63  0
  12. 3  0      0 936268  27256 948088    0    0     0     0 5607 1790  4 34 63  0
复制代码

评分

参与人数 1可用积分 +5 收起 理由
cryboy2001 + 5 很给力!

查看全部评分

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

SACC2019中国系统架构师大会

【数字转型 架构演进】SACC2019中国系统架构师大会
2019年10月31日~11月2日第11届中国系统架构师大会(SACC2019)将在北京隆重召开。四大主线并行的演讲模式,1个主会场、20个技术专场、超千人参与的会议规模,100+来自互联网、金融、制造业、电商等领域的嘉宾阵容,将为广大参会者提供一场最具价值的技术交流盛会。




----------------------------------------

大会官网>>
  

北京盛拓优讯信息技术有限公司. 版权所有 16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122
中国互联网协会会员  联系我们:huangweiwei@it168.com
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP