Erlang C1500K长连接推送服务-性能

Whatsapp已经使用Erlang在生产环境跑到96GB内存单机 3M长连接,参加:WhatsApp的Erlang世界。毕竟业务级别能达到Whatsapp那样极少,现在只有千万级,单机太多挂一台影响太大,再者就是没有多线接入,每个机房都得扔那么几台机器吧,所以1M就能满足要求。

Erlang 作为长连接网关有着天生的优势:

- 擅长与IO密集型业务,也要求将网关设计尽量简单,认证完后,简单解析报头,就直接将请求转发给后端服务处理

- 网络层有beam c 实现得非常高效 ,erlang 代码只是简单流程控制,也就是说代码性能很接近优化的很好c程序

- 代码简单,易维护,erlang 进程和连接一对一关系,代码500行左右

- 基于进程GC,node 内存多大也不用担心stop of word

- 热升级,网关设计本尽量简单,减少升级,但也不可避免,热升级保证不断连接

- 稳定,beam 足够稳定,即使天天更新的服务,连续一两年不重启也正常

- 多语言混合,后端可很容易使用其他语言实现

 

劣势:CPU密集型业务,性能差,如果不想用c解包,尽量使用二进制协议,尽量将包协议标识放在包体固定位置,方便dispatch

 

1. 测试环境

  - 服务端: R620 2*(E5-2620 6核心12线程)/mem:128GB

  - 客户端:R620 2*(E5-2620 6核心12线程)/mem:48GB(5台*5 IP,共25IP)

 

2. 调优

  1. beam 启动参数

  +sbt db 绑定调度器与CPU的亲缘性

  +P 2000000 进程数限制(合适即可)

  +K true 启用epoll

  +sbwt none 关闭beam 调度器 spinlock,降低CPU

  +swt low 提高调度器唤醒灵敏度,避免长时间运行睡死问题

  参考我另外一篇:erlang cpu 相关参数调整

 

  2. Erlang 网络库:ranch 需要修改

    - 配置acceptors 数量1024,backlog 32768

    同时系统backlog调整: net.core.somaxconn, net.core.netdev_max_backlog, net.ipv4.tcp_max_syn_backlog 32768

    - 删除新加连接时的 ranch_sup 和 connection monitor,占用内存且用处不大,同时单进程热点问题,也造成backlog 无法及时处理

    - acceptor 设置 process_flag(prority, high),否则因为公平调度问题,即使CPU不高,backlog 无法及时得到处理

 

       3. Erlang内存占用

   因为Erlang GC 基于进程,每个连接对应一个进程,每个连接的业务量都很小。那样就会造成一种现象数百w进程内都有一点垃圾,无法得到GC。

   使用hibernate,erlang:hibernate 会清空但前调用栈,并强制GC,下次进程收到消息后,会通过参数MFA继续执行。

   使用gen_server 简单的在没有个包处理完后,都加上hibernate, CPU无明显增加情况下,可将内存使用降低到1/3 以下,非常值得使用。

 

3. 压测场景

  - 客户端在5台机器,25个IP,开启 tcp_tw_reuse tcp_tw_recycle 后每个IP稳定跑6w连接还是没问题的。

  - 6K/s 登陆、认证、心跳、退出 操作

  - 1w/s 消息推送、ack

  - 运行12 小时

 

4. 结果

 ss -s
Total: 1500254 (kernel 1500317)
TCP:   1500090 (estab 1500077, closed 0, orphaned 0, synrecv 0, timewait 0/0), ports 74

Transport Total     IP        IPv6
*      1500317   -         -
RAW      0         0         0
UDP      0         0         0
TCP      1500090   1500090   0
INET      1500090   1500090   0
FRAG      0         0         0

 

  网关机器:

  - CPU 500%

  - 网卡 6w/s tcp packet in/out

  - node mem 12GB (内部memory(total) 显示实际使用9GB)

  - kernel mem 11GB

 

  - 也就是150w连接,使用了23GB内存,每个连接占用15KB,约一半是内核使用,erlang 使用内存并不多。

  - 在如此业务量压力下,500% CPU表现也不俗,随无法和c相比,但其多核扩展性好。

  - 服务器有24核心,但环境其他服务、客户端IP数限制,没有继续增大压力,理论上单机200~300w 连接,5w/s 消息推送 应该不是问题。

posted @ 2014-11-30 00:05 LittlePeng 阅读(...) 评论(...) 编辑 收藏