100万并发连接服务器笔记之测试端就绪

标签: 并发 服务器 笔记 | 发表时间:2013-04-10 11:07 | 作者:nieyong
出处:http://www.blogjava.net/

重新编写测试端程序

测试端程序需要增加绑定本机IP和本地端口的功能,以尽可能的向外发出更多的tcp请求。需要对client1.c重构,增加参数传递。 下面是client2.c的代码

若不指定端口,系统会随机挑选没有使用到的端口,可以节省些心力。

编译:

  gcc -o client2 client2.c -levent

参数解释

  • -h 要连接的服务器IP地址
  • -p 要连接的服务器端口
  • -m 本机IP地址需要绑定的随机端口数量
  • -o 本机所有可用的IP地址列表,注意所有IP地址都应该可用

运行:

  ./client2 -h 192.168.190.230 -p 8000 -m 64000 -o 192.168.190.134,192.168.190.143,192.168.190.144,192.168.190.145,192.168.190.146,192.168.190.147,192.168.190.148,192.168.190.149,192.168.190.150,192.168.190.151

太长了,每次执行都要粘贴过去,直接放在一个client2.sh文件中,执行就很简单方便多了。

  #!/bin/sh
./client2 -h 192.168.190.230 -p 8000 -m 64000 -o 192.168.190.134,192.168.190.143,192.168.190.144,192.168.190.145,192.168.190.146,192.168.190.147,192.168.190.148,192.168.190.149,192.168.190.150,192.168.190.151

保存,赋值可运行:

  chmod +x client2.sh

启动测试:

  sh client2.sh

第三个遇到的问题:fs.file-max的问题

测试端程序client2.c在发出的数量大于某个值(大概为40万时)是,通过 dmesg命令查看会得到大量警告信息:

  [warn] socket: Too many open files in system

此时,就需要检查 /proc/sys/fs/file-max参数了。

查看一下系统对fs.file-max的说明

   /proc/sys/fs/file-max
 This file defines a system-wide limit on the number of open files for all processes. (See also setrlimit(2), which can be used by a process to set the per-process limit,
 RLIMIT_NOFILE, on the number of files it may open.) If you get lots of error messages about running out of file handles, try increasing this value:
 echo 100000 > /proc/sys/fs/file-max
 The kernel constant NR_OPEN imposes an upper limit on the value that may be placed in file-max.
 If you increase /proc/sys/fs/file-max, be sure to increase /proc/sys/fs/inode-max to 3-4 times the new value of /proc/sys/fs/file-max, or you will run out of inodes.

file-max表示系统所有进程最多允许同时打开所有的文件句柄数,系统级硬限制。Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制,如果没有特殊需要,不用修改,除非打开的文件句柄数超过此值。

在为测试机分配4G内存时,对应的fs.file-max值为386562,很显然打开的文件句柄很受限,38万个左右。 很显然,无论是测试端还是服务端,都应该将此值调大些,一定要大于等于/etc/security/limits.conf送所设置的soft nofile和soft nofile值。
注意ulimit -n,仅仅设置当前shell以及由它启动的进程的资源限制。

备注:以上参数,具有包含和被包含的关系。

当前会话修改,可以这么做:

  echo 1048576 > /proc/sys/fs/file-max

但系统重启后消失。

永久修改,要添加到 /etc/sysctl.conf 文件中:

  fs.file-max = 1048576

保存并使之生效:

  sysctl -p

再测,就不会出现此问题了。

一台6G内存机器测试机,分配7个网卡,可以做到不占用虚拟内存,对外发出64000 * 7 = 448000个对外持久请求。要完成100万的持久连接,还得再想办法。

最终测试端组成如下:

  • 两台物理机器各自一个网卡,每个发出64000个请求
  • 两个6G左右的centos测试端机器(绑定7个桥接或NAT连接)各自发出64000*7 = 448000请求
  • 共使用了16个网卡(物理网卡+虚拟网卡)
  • 1M ≈ 1024K ≈ 1024000 = (64000) + (64000) + (64000 7) + (640007)
  • 共耗费16G内存,16个网卡(物理+虚拟),四台测试机

备注:
下面就要完成1M持久连接的目标,但在服务端还会遇到最后一个问题。



nieyong 2013-04-10 11:07 发表评论

相关 [并发 服务器 笔记] 推荐:

100万并发连接服务器笔记之准备篇

- - BlogJava-首页技术区
测试一个非常简单服务器如何达到100万(1M=1024K连接)的并发连接,并且这些连接一旦连接上服务器,就不会断开,一直连着. 环境受限,没有服务器,刚开始都是在自己的DELL笔记本上测试,凭借16G内存,和优秀的vmware workstation虚拟机配合,另外还得外借别人虚拟机使用,最终还得搭上两台2G内存的台式机(安装centos),最终才完成1M并发连接任务.

100万并发连接服务器笔记之测试端就绪

- - BlogJava-首页技术区
测试端程序需要增加绑定本机IP和本地端口的功能,以尽可能的向外发出更多的tcp请求. 需要对client1.c重构,增加参数传递. 下面是client2.c的代码. 若不指定端口,系统会随机挑选没有使用到的端口,可以节省些心力. -h 要连接的服务器IP地址. -m 本机IP地址需要绑定的随机端口数量.

100万并发连接服务器笔记之1M并发连接目标达成

- - BlogJava-首页技术区
第四个遇到的问题:tcp_mem. 在服务端,连接达到一定数量,诸如50W时,有些隐藏很深的问题,就不断的抛出来. 通过查看 dmesg命令查看,发现大量 TCP: too many of orphaned sockets错误,也很正常,下面到了需要调整tcp socket参数的时候了. 第一个需要调整的是tcp_rmem,即TCP读取缓冲区,单位为字节,查看默认值.

100万并发连接服务器笔记之Erlang完成1M并发连接目标

- - BlogJava-首页技术区
使用Erlang语言也写一个测试和前面大同小异的测试,在100万个并发连接用户情况下,就是想观察一下极显情况下的表现. 这个测试使用了优秀的Erlang界的明星框架. cowboy,加单易用的接口,避免了我们对HTTP栈再次进行闭门造车. 运行在VMWare Workstation 9中,64位Centos 6.4系统,分配14.9G内存左右,双核4个线程,服务器安装Erlang/OTP R16B,最新版本支持异步代码热加载,很赞.

100万并发连接服务器笔记之Java Netty处理1M连接会怎么样

- - BlogJava-首页技术区
每一种该语言在某些极限情况下的表现一般都不太一样,那么我常用的Java语言,在达到100万个并发连接情况下,会怎么样呢,有些好奇,更有些期盼. netty NIO框架(netty-3.6.5.Final),封装的很好,接口很全面,就像它现在的域名 netty.io,专注于网络IO. 整个过程没有什么技术含量,浅显分析过就更显得有些枯燥无聊,准备好,硬着头皮吧.

笔记: Xen VM 里面的 MySQL 服务器优化

- - #raynix's notes
我一直都对公司 Xen VM 的数据库服务器不满, 因为实在是太慢了. 但是几百个 GB 的商业数据我可不敢动, 于是先在测试服务器上证实一下我的想法. 硬盘就是普通的 SATA 7200RPM, VM 用的是 LVM 分区. 然后我用之前写的一个小程序做批量更新, 32K 记录. 缺省配置下, 运行时长达到24分钟, 而优化后则只需要27秒.

java并发编程实践学习笔记

- - zzm
    原子操作:原子为不可再分操作.    Violation :可见关键字.    Synchronized:内部隐示锁 .    ReentrantLock:显示锁 .    ReentrantReadWriteLock:读写锁 . jmm(java内存模型):. 线程对所有变量的操作都是在工作内存中进行,线程之间无法相互直接访问,变量传递 均需要通过主存完成.

笔记

- 毛毛 - 游戏人生
我关于写代码的一些琐碎的看法. 之前没有把 Paul Graham 的 <黑客与画家> 一书读完, 上周就从同事那里把书带回家, 也一直没读, 到这周才有时间读完. 很久没有更新了 (一看时间, 整整 5 个月), 顺便把这篇写了几个月的感想放出来.. 这本书前面 8 章讲述的内容, 大多是我并不太感兴趣的, 比如财富, 比如创业.

kernel.org服务器遭入侵

- Lamo - Solidot
kernel.org网站首页发布公告,声称多台服务器在本月初(8月12日前)遭黑客攻击,他们在8月28日发现了入侵. 入侵者利用一位用户凭证获得了服务器根访问权限,他们正在调查黑客是如何提升权限的;系统启动脚本被加入了一个木马启动文件;ssh相关文件被修改. kernel.org声称,他们相信Linux kernel源代码库未受影响,因为git分布式版本控制系统的特性决定了它可以很容易注意到代码变化.

Ubuntu下赌ARM服务器

- Tim - Solidot
今日无数手机平板使用的低能耗处理器能否撑起未来的服务器市场. Canonical计划推出支持ARM架构的Ubuntu服务器版本. Ubuntu Linux并不是x86服务器市场的重量级选手,Red Hat才是. 但通过与ARM合作打造ARM服务器,Canonical正努力赢得更多市场份额. 计划于2011年10月发布的Ubuntu Server 11.10,将同步推出支持x86、x86-64和ARM架构的版本.