• 1. C1000K高性能服务器构建技术余锋 http://yufeng.info mryufeng@gmail.com 淘宝网核心系统资深专家   2010/10/16
  • 2. C1000K面对的挑战C10K问题:http://www.kegel.com/c10k.html 时间是2001年   现在是2010年,10年过去了,虽然软硬件技术也相应提高了,   挑战还在:    用户对服务响应时间和可靠性要求越来越高。  1M的tcp并发,即使每个链接按照16K内存算,需要至少24G内存。 1M的tcp链接中,有20%每秒活跃,那么200K每秒。 没有革命性的技术改进,算法和操作系统和库变化不大。 硬件,操作系统,库,平台,应用的层次越来越深。    硬件约束:Dell R710, Intel E5520 *2(8core),  24G内存, 640G SAS
  • 3. 解决方案顺应硬件和操作系统的变化方向,高度并发化应用!让独立的CPU核心,独立的cache,  独立的本地内存,独立的(soft)IRQ,独立的网卡,独立的磁盘,独立的Erlang调度器,独立的Erlang进程服务你的每个独立的请求!
  • 4. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论  
  • 5. 硬件体系巨大变化现在过去北桥慢慢成为过去!
  • 6. Dell R710机器体系结构
  • 7. Cache在现代CPU硬件上的版面, 也充分说明了cache的重要性!!!
  • 8. 内置六块磁盘, 四张网卡如何高效并行使用?
  • 9. Virident pci-e卡 IOPS高达200K,带宽800M
  • 10. 小结  硬件变得和过去很不一样,性能越来越高。   硬件从CPU,内存,网卡都在试图scale, 我们要配合硬件的并行化趋势。   硬件在cache方面下了很多血本,提高数据的locality。   采用合适的硬件,比如说ssd盘代替sas盘。    
  • 11. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论
  • 12. 深度调查系统,为设计做依据
  • 13. Numa架构下的调度器,CPU亲缘性
  • 14. Numa mattersgoogle Tcmalloc numa aware 版本Numa不同的节点间访问代价不同。 不适当的设置,会导致有的节点的内存空闲,有的需要swap。 libnuma改善内存分配的亲缘性, numactl 改变内存分配的策略。 /proc/pid/numa_maps了解你的进程内存在节点间的分布情况。
  • 15. Largepage TLB miss的代价   过去4K一页 现在通过HugeTLBfs实现 2M一页   大大减少TLB miss   oprofile可以告诉我们tlb的miss率
  • 16. 网卡bonding    我们需要网卡的负载均衡模式(mode 0), 需要交换机的支持
  • 17. 中断平衡硬中断:       irqbalance 智能的均衡硬件中断。 手动 [root@linux /]#echo ff > /proc/irq/19/smp_affinity    软中断:        
  • 18. RPS/RFS  解决softirq平衡RPS is not automatically switched on, you have to configure it.   echo ffff >/sys/class/net/eth0/queues/rx-0/rps_cpus Same for RFS if you prefer to use RFS echo 16384 >/sys/class/net/eth0/queues/rx-0/rps_flow_cn   显著提高软中断的均衡性,大大提高性能。       
  • 19. 微调协议栈原则: dmesg可以观察到协议栈在抱怨什么,它抱怨什么我们解决什么!TCP协议栈内存 不可交换物理内存
  • 20. 来自google的initcwnd调优通过提高初始拥塞窗口的大小(3),大大减少短连接的响应时间.   make sure your Linux kernel is 2.6.30 or higher.    ip route change [default via a.b.c.d dev ethX ... ] initcwnd 10
  • 21. IO子系统  磁盘硬件的选择 文件系统的选择 IO调动算法的选择 page cache的设置 不同类型的IO系统调用   对IO的性能都有很多的影响!   让FIO测试工具告诉你答案!
  • 22. 采用异步IO异步IO的好处, 应用批量提交请求,方便IO调动器合并请求,减少磁盘寻道和访问次数.   libaio: Linux native aio的封装, 在使用上可以用Linux eventfd做事件通知, 融入到Erlang的IO check机制。   glibc aio是用线程+同步调用模拟的,完全不可用!   多线程同时发起IO请求。   注意要保持快速IO设备队列的请求depth。
  • 23. 小结   采用64位Linux操作系统。   充分利用负载均衡技术,提高CPU和cache的利用率。   尽量用最新的linux内核,用降低稳定性,保持高性能。比如说Oracle的Linux在运行数据库时号称比RHEL5快85%。   尽量用新的能够提高性能的syscall,新特性。   常态监测你的系统,找出导致性能减低的点,加以解决。
  • 24. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论
  • 25. 你需要知道的访问延迟数字  
  • 26. 多核心架构下性能问题, CPU和内存以及IO间的速度越来越不平衡,CPU大部分时间都是在等待。
  • 27. 如何利用好我们的cache和空余CPU计算力?Intel Xeon 7400 CPU: 96 KB L1 cache (Data) and 16 MB of L3 cache 
  • 28. 压缩数据集主存的访问速度很慢: 8G/s,  L1:300G/s。    压缩我们的数据在传送,到目的地后解压,比直接传送要快。   Lzo  解压速度巨快,接近于memcpy, 压缩率大概在50%.   压缩速度比解压慢2-3倍, 对于读多写少的情况比较适合。    ramzswap显示压缩squid内存索引的压缩率: OrigDataSize: 1968516 kB ComprDataSize: 862015 kB
  • 29. 列表[]数据结构Erlang的[] 注意事项:   1.  单链表,只能表头访问,数据分散, 特别是数据被GC过后,中间的洞变大,对cache很不友好。   2.  Erlang的IO支持 iolist, 底层会用writev发送数据,尽量用iolist.  
  • 30. 避免数据搬动使用更聪明的数据结构。 (vm)splice,  sendfile: 减少内核和用户空间的数据搬动 。 readv/writev:  尽量gather read, scatter write。 合并你的数据,一次写入,cache line 64Byte, 页面是4K单位,IO操作的unit是页面。
  • 31. 小结利用好cache 提高数据的locality。 采用更高效的算法。 CPU大部分时间在空闲,等数据, 可以用时间换空间。 减少内存的搬动。 采用更快的编译器编译应用,比如说Intel ICC, 通常能快百分小几十。 numa aware的内存分配池。
  • 32. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论
  • 33. Erlang运行期内部结构图虚拟机的选择SMP版本和Plain版本,由erlexec动态选择根据参数选择。 VM内部启用Hipe与否。 64位机器下halfword版本。
  • 34. 调度器机制Running on full load or not!进程和BIF按照时间片原则公平调度,抢占。
  • 35. 绑定调度器spawn_opt 未公开参数 scheduler 用于绑定进程到指定调度器
  • 36. Erlang 进程和Port进程和现实世界1:1映射。 进程是根据时间片实现抢占式公平调度。 每个进程独立的堆和栈,独立的进行GC, 消息通过拷贝的方式传递。 Tcp port也是和现实世界1:1映射。  Port通过Kernel Poll来实现事件监测 ,IO调动独立于进程调度,也是公平调度。 每个tcp port内部都有发送队列(高低水位线),以及接收缓冲区。 port和进程的slot位都是预先分配好的。    
  • 37. Erlang内存分配池Numa aware 何时支持? R14B? largepage 何时支持?   内部有几百个分门别类的内存池。   mseg_alloc: 通过mmap来向系统申请内存,批发给其他内存分配池。   每个调度器自己的内存池。
  • 38. Erlang 进程单点/race问题已知有单点的模块:  disk_log模块  rpc  ...   已知有race的模块 ets mnesia erlang:register/unregister       日志系统: 内置的太慢,推荐自己用linux shm来实现个ring buf。          
  • 39. Erlang NIFR14新添加的,丰富的接口,容易用C库扩展Erlang的功能。 NIF不像bif那样有trap机制,破坏Erlang调度器的抢占式调动。 NIF千万不要调用阻塞函数, 比如调用mysql库。 NIF有很大稳定性风险,错误会影响到整个VM。  
  • 40. EI (erlang C interface)最近版本的EI修复了很多bug, 稳定了很多。 轻量,配合libev库做tcp链接接入服务器是非常好的选择。 丰富的RPC调用接口,直接访问后端Erlang服务器的模块。 支持多线程,多实例。 直接在shell下使用erl_call。
  • 41. MnesiaOTP最核心的部件Mnesia,是做分布式系统最关键的一环!
  • 42. 小结并行化进程,按照1:1映射到现实世界。 Erlang的调度器绑定,提高cach的利用率。 halfword VM减少64位机器上的内存浪费。 开启Hipe Jit功能,  同时用native方式编译库和应用。 尽量使用binary,最贴近机器内存模型,cache友好。 hipe 内置的未公开的bif 进程字典 留意你的进程的最大文件句柄数, 太大会浪费很多资源。 留意你的IO需要的异步线程, +A size参数。  
  • 43. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论
  • 44. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论
  • 45. 推荐的性能调优工具操作系统层面的: systemtap oprofile blktrace tsung gdb lmbench   Erlang平台上的: lcnt dialyzer 内置的自省机制 cerl      
  • 46. 了解IO系统性能测试工具:     Fio  测试多种IO的效率 (sync, mmap, libaio, posixaio...)     Sysbench  简单易用的测试工具     Iozone  侧重文件系统以及应用的数据访问模式    IO监视工具    Blktrace     btt  可视化你的IO活动    seekwatcher 可视化你的磁头移动   其他工具 slabtop      
  • 47. ss用于统计大量socket占用的资源情况netstat之类的工具对于大量的链接来讲实在太慢!了!
  • 48. Systemtap帮助你了解你的程序/OS
  • 49. Agenda硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang平台层面变化和思考 调优工具 结论
  • 50. 结论C1000K离我们很近的,几年后技术就会普及。 C1000K是个渐近的过程,点滴成就高性能。 C1000K需要软硬件技术的高度配合,需要关心的层次很深, 是个系统工程。 C1000K随着应用和构造工具的不同,难度也变化的很大。 C1000K用Erlang平台构造最不痛苦(个人感觉)。         祝大家C1000K的开心!
  • 51. 谢谢大家!Any question? 大部分的图片粘贴自Google搜索的文档,谢谢Google,谢谢这些可爱的作者。