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

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

前言

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

测试服务器配置

运行在VMWare Workstation 9中，64位Centos 6.2系统，分配14.9G内存左右，4核。
已安装有Java7版本：

  java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

测试端

测试端和以前一样的程序，翻看前几篇博客就可以看到client5.c的源码。

在/etc/sysctl.conf中添加如下配置：

  fs.file-max = 1048576
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_mem = 786432 2097152 3145728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

服务器程序

这次也是很简单呐，没有业务功能，客户端HTTP请求，服务端输出chunked编码内容。

入口HttpChunkedServer.java：

唯一的自定义处理器HttpChunkedServerHandler.java:

启动脚本start.sh

达到100万并发连接时的一些信息

每次服务器端达到一百万个并发持久连接之后，然后关掉测试端程序，断开所有的连接，等到服务器端日志输出在线用户为0时，再次重复以上步骤。在这反反复复的情况下，观察内存等信息的一些情况。以某次断开所有测试端为例后，当前系统占用为（设置为 list_free_1）:

                    total       used       free     shared    buffers     cached
     Mem:         15189       7736       7453          0         18        120
     -/+ buffers/cache:       7597       7592
     Swap:         4095        948       3147

通过top观察，其进程相关信息

      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                       
   4925 root      20   0 8206m 4.3g 2776 S  0.3 28.8  50:18.66 java

在启动脚本start.sh中，我们设置堆内存为6G。

ps aux|grep java命令获得信息：

    root      4925 38.0 28.8 8403444 4484764 ?     Sl   15:26  50:18 java -server...HttpChunkedServer 8000

RSS占用内存为4484764K/1024K=4379M

然后再次启动测试端，在服务器接收到 online user 1023749时， ps aux|grep java内容为：

    root      4925 43.6 28.4 8403444 4422824 ?     Sl   15:26  62:53 java -server...

查看当前网络信息统计

    ss -s
  Total: 1024050 (kernel 1024084)
  TCP:   1023769 (estab 1023754, closed 2, orphaned 0, synrecv 0, timewait 0/0), ports 12

  Transport Total     IP        IPv6
  *    1024084   -         -        
  RAW     0         0         0        
  UDP     7         6         1        
  TCP     1023767   12        1023755  
  INET    1023774   18        1023756  
  FRAG    0         0         0

通过top查看一下

    top -p 4925
  top - 17:51:30 up  3:02,  4 users,  load average: 1.03, 1.80, 1.19
  Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
  Cpu0  :  0.9%us,  2.6%sy,  0.0%ni, 52.9%id,  1.0%wa, 13.6%hi, 29.0%si,  0.0%st
  Cpu1  :  1.4%us,  4.5%sy,  0.0%ni, 80.1%id,  1.9%wa,  0.0%hi, 12.0%si,  0.0%st
  Cpu2  :  1.5%us,  4.4%sy,  0.0%ni, 80.5%id,  4.3%wa,  0.0%hi,  9.3%si,  0.0%st
  Cpu3  :  1.9%us,  4.4%sy,  0.0%ni, 84.4%id,  3.2%wa,  0.0%hi,  6.2%si,  0.0%st
  Mem:  15554336k total, 15268728k used,   285608k free,     3904k buffers
  Swap:  4194296k total,  1082592k used,  3111704k free,    37968k cached

    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                       
   4925 root      20   0 8206m 4.2g 2220 S  3.3 28.4  62:53.66 java

四核都被占用了，每一个核心不太平均。这是在虚拟机中得到结果，可能真实服务器会更好一些。 因为不是CPU密集型应用，CPU不是问题，无须多加关注。

系统内存状况

    free -m
               total       used       free     shared    buffers     cached
  Mem:         15189      14926        263          0          5         56
  -/+ buffers/cache:      14864        324
  Swap:         4095       1057       3038

物理内存已经无法满足要求了，占用了1057M虚拟内存。

查看一下堆内存情况

    jmap -heap 4925
  Attaching to process ID 4925, please wait...
  Debugger attached successfully.
  Server compiler detected.
  JVM version is 23.21-b01

  using parallel threads in the new generation.
  using thread-local object allocation.
  Concurrent Mark-Sweep GC

  Heap Configuration:
     MinHeapFreeRatio = 40
     MaxHeapFreeRatio = 70
     MaxHeapSize      = 6442450944 (6144.0MB)
     NewSize          = 629145600 (600.0MB)
     MaxNewSize       = 629145600 (600.0MB)
     OldSize          = 5439488 (5.1875MB)
     NewRatio         = 2
     SurvivorRatio    = 1
     PermSize         = 52428800 (50.0MB)
     MaxPermSize      = 52428800 (50.0MB)
     G1HeapRegionSize = 0 (0.0MB)

  Heap Usage:
  New Generation (Eden + 1 Survivor Space):
     capacity = 419430400 (400.0MB)
     used     = 308798864 (294.49354553222656MB)
     free     = 110631536 (105.50645446777344MB)
     73.62338638305664% used
  Eden Space:
     capacity = 209715200 (200.0MB)
     used     = 103375232 (98.5863037109375MB)
     free     = 106339968 (101.4136962890625MB)
     49.29315185546875% used
  From Space:
     capacity = 209715200 (200.0MB)
     used     = 205423632 (195.90724182128906MB)
     free     = 4291568 (4.0927581787109375MB)
     97.95362091064453% used
  To Space:
     capacity = 209715200 (200.0MB)
     used     = 0 (0.0MB)
     free     = 209715200 (200.0MB)
     0.0% used
  concurrent mark-sweep generation:
     capacity = 5813305344 (5544.0MB)
     used     = 4213515472 (4018.321487426758MB)
     free     = 1599789872 (1525.6785125732422MB)
     72.48054631000646% used
  Perm Generation:
     capacity = 52428800 (50.0MB)
     used     = 5505696 (5.250640869140625MB)
     free     = 46923104 (44.749359130859375MB)
     10.50128173828125% used

  1439 interned Strings occupying 110936 bytes.

老生代占用内存为72%，较为合理，毕竟系统已经处理100万个连接。

再次断开所有测试端，看看系统内存（free -m）

                 total       used       free     shared    buffers     cached
  Mem:         15189       7723       7466          0         13        120
  -/+ buffers/cache:       7589       7599
  Swap:         4095        950       3145

记为 list_free_2。

list_free_1和 list_free_2两次都释放后的内存比较结果，系统可用物理已经内存已经降到7589M，先前可是7597M物理内存。
总之，我们的JAVA测试程序在内存占用方面已经，最低需要7589 + 950 = 8.6G内存为最低需求内存吧。

GC日志

我们在启动脚本处设置的一大串参数，到底是否达到目标，还得从gc日志处获得具体效果，推荐使用 GCViewer。

GC事件概览：
gc_eventdetails

其它:
gc_total_1  gc_total_2 gc_total_3

总之：

  • 只进行了一次Full GC，代价太高，停顿了12秒。
  • PartNew成为了停顿大户，导致整个系统停顿了41秒之久，不可接受。
  • 当前JVM调优喜忧参半，还得继续努力等

小结

Java与与Erlang、C相比，比较麻烦的事情，需要在程序一开始就得准备好它的堆栈到底需要多大空间，换个说法就是JVM启动参数设置堆内存大小，设置合适的垃圾回收机制，若以后程序需要更多内存，需停止程序，编辑启动参数，然后再次启动。总之一句话，就是麻烦。单单JVM的调优，就得持续不断的根据检测、信息、日志等进行适当微调。

  • JVM需要提前指定堆大小，相比Erlang/C，这可能是个麻烦
  • GC(垃圾回收)，相对比麻烦，需要持续不断的根据日志、JVM堆栈信息、运行时情况进行JVM参数微调
  • 设置一个最大连接目标，多次测试达到顶峰，然后释放所有连接，反复观察内存占用，获得一个较为合适的系统运行内存值
  • Eclipse Memory Analyzer结合jmap导出堆栈DUMP文件，分析内存泄漏，还是很方便的
  • 想修改运行时内容，或者称之为热加载，默认不可能
  • 真实机器上会有更好的反映

吐槽一下：
JAVA OSGI，相对比Erlang来说，需要人转换思路，不是那么原生的东西，总是有些别扭，社区或商业公司对此的修修补补，不过是实现一些面向对象所不具备的热加载的企业特性。

测试源代码， 下载just_test。



nieyong 2013-05-13 11:16 发表评论

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

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架构的版本.