C1000K高性能服务器构建技术

C1000K高性能服务器构建技术淘宝网核心系统资深专家2010/10/16C1000K面对的挑战C10K问题：时间是2001年现在是2010年，10年过去了，虽然软硬件技术也相应提高了，挑战还在:•用户对服务响应时间和可靠性要求越来越高。•1M的tcp并发，即使每个链接按照16K内存算，需要至少24G内存。•1M的tcp链接中，有20%每秒活跃，那么200K每秒。•没有革命性的技术改进，算法和操作系统和库变化不大。•硬件，操作系统，库，平台，应用的层次越来越深。硬件约束：DellR710，IntelE5520*2,24G内存，640GSAS解决方案顺应硬件和操作系统的变化方向，高度并行化应用！让独立的网卡，独立的CPU核心，独立的cache,独立的本地内存，独立的(soft)IRQ，独立的Erlang调度器，独立的Erlang进程服务你的每个独立的请求!图!图!图!Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论DellR710机器硬件体系巨大变化现在过去北桥慢慢成为过去！Cache在现代CPU硬件上的版面，也充分说明了cache的重要性内置四张网卡如何高效并行使用？Viridentpci-e卡IOPS高达200K，带宽800M小结•硬件变得和过去很不一样，性能越来越高。•硬件从CPU，内存，网卡都在试图scale，我们要配合硬件的并行化趋势。•硬件在cache方面下了很多血本，提高数据的locality。•采用合适的硬件，比如说ssd盘代替sas盘。Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论深度调查系统，为设计做依据Numa架构下的调度器，CPU亲缘性NumamattersgoogleTcmallocnumaaware版本•Numa不同的节点间访问代价不同。•不适当的设置,会导致有的节点的内存空闲，有的需要swap。•libnuma改善内存分配的亲缘性,numactl改变内存分配的策略。•/proc/pid/numa_maps了解你的进程内存在节点间的分布情况。LargepageTLBmiss的代价过去4K一页现在通过HugeTLBfs实现2M一页大大减少TLBmissoprofile可以告诉我们tlb的miss率网卡bonding我们需要网卡的负载均衡模式（mode0),需要交换机的支持中断平衡硬中断:•irqbalance智能的均衡硬件中断。•手动[root@linux/]#echoff/proc/irq/19/smp_affinity软中断:RPS/RFS解决softirq平衡RPSisnotautomaticallyswitchedon,youhavetoconfigureit.echoffff/sys/class/net/eth0/queues/rx-0/rps_cpusSameforRFSifyouprefertouseRFSecho16384/sys/class/net/eth0/queues/rx-0/rps_flow_cn显著提高软中断的均衡性，大大提高性能。微调协议栈原则：dmesg可以观察到协议栈在抱怨什么，它抱怨什么我们解决什么！TCP协议栈内存不可交换物理内存来自google的initcwnd调优通过提高初始拥塞窗口的大小(3)，大大减少短连接的响应时间.makesureyourLinuxkernelis2.6.30orhigher.iproutechange[defaultviaa.b.c.ddevethX...]initcwnd10IO子系统•磁盘硬件的选择•文件系统的选择•IO调动算法的选择•pagecache的设置•不同类型的IO系统调用对IO的性能都有很多的影响！让FIO测试工具告诉你答案!采用异步IO异步IO的好处，应用批量提交请求，方便IO调动器合并请求，减少磁盘寻道和访问次数.libaio:Linuxnativeaio的封装,在使用上可以用Linuxeventfd做事件通知,融入到Erlang的IOcheck机制。glibcaio是用线程+同步调用模拟的，完全不可用！多线程同时发起IO请求。注意要保持快速IO设备队列的请求depth。小结•采用64位Linux操作系统。•充分利用负载均衡技术，提高CPU和cache的利用率。•尽量用最新的linux内核，用降低稳定性，保持高性能。比如说Oracle的unbreakableLinux号称比RHEL5快85%。•尽量用新的能够提高性能的syscall，新特性。•常态监测你的系统，找出导致性能减低的点，加以解决。Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论你需要知道的访问延迟数字多核心架构下性能问题，CPU和内存以及IO间的速度越来越不平衡，CPU大部分时间都是在等待。如何利用好我们的cache和空余CPU计算力？IntelXeon7400CPU:96KBL1cache(Data)and16MBofL3cache压缩数据集主存的访问速度很慢:8G/s,L1:300G/s。压缩我们的数据在传送，到目的地后解压，比直接传送要快。Lzo解压速度巨快，接近于memcpy,压缩率大概在50%.压缩速度比解压慢2-3倍，对于读多写少的情况比较适合。ramzswap显示压缩squid内存索引的压缩率：OrigDataSize:1968516kBComprDataSize:862015kB列表[]数据结构Erlang的[]注意事项：1.单链表，只能表头访问，数据分散，特别是数据被GC过后，中间的洞变大，对cache很不友好。2.Erlang的IO支持iolist,底层会用writev发送数据，尽量用iolist.避免数据搬动•使用更聪明的数据结构。•(vm)splice,sendfile:减少内核和用户空间的数据搬动。•readv/writev:尽量gatherread,scatterwrite。•合并你的数据，一次写入，页面是4K单位，IO操作的unit是页面。小结•利用好cache提高数据的locality。•采用更高效的算法。•CPU大部分时间在空闲，等数据,可以用时间换空间。•减少内存的搬动。•采用更快的编译器编译应用，比如说IntelICC,通常能快百分小几十。•numaaware的内存分配池。Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论Erlang运行期内部结构图虚拟机的选择•SMP版本和Plain版本，由erlexec动态选择根据参数选择。•VM内部启用Hipe与否。•64位机器下halfword版本。调度器机制Runningonfullloadornot!进程和BIF按照时间片原则公平调度，抢占。绑定调度器spawn_opt未公开参数scheduler用于绑定进程到指定调度器Erlang内存分配池Numaaware何时支持？R14B？largepage何时支持？内部有几百个分门别类的内存池。mseg_alloc：通过mmap来向系统申请内存，批发给其他内存分配池。每个调度器自己的内存池。Erlang进程和Port•进程和现实世界1:1映射。•进程是根据时间片实现抢占式公平调度。•每个进程独立的堆和栈，独立的进行GC,消息通过拷贝的方式传递。•Tcpport也是和现实世界1：1映射。•Port通过KernelPoll来实现事件监测，IO调动独立于进程调度，也是公平调度。•每个tcpport内部都有发送队列（高低水位线），以及接受缓冲区。•port和进程的slot位都是预先分配好的。Erlang进程单点/race问题已知有单点的模块：•x•y已知有race的模块•ets•mnesia•erlang:register/unregister日志系统：•内置的太慢，推荐自己用linuxshm来实现个ringbuf。ErlangNIF•R14新添加的，丰富的接口，容易用C库扩展Erlang的功能。•NIF不像bif那样有trap机制，破坏Erlang调度器的抢占式调动。•NIF千万不要调用阻塞函数，比如调用mysql库。•NIF有很大稳定性风险，错误会影响到整个VM。EI(erlangCinterface)•最近版本的EI修复了很多bug,稳定了很多。•轻量，配合libev库做tcp链接接入服务器是非常好的选择。•丰富的RPC调用接口，直接访问后端Erlang服务器的模块。•支持多线程，多实例。•直接在shell下使用erl_call。MnesiaOTP最核心的部件Mnesia，是做分布式系统最关键的一环！小结•并行化进程，按照1:1映射到现实世界。•Erlang的调度器绑定，提高cach的利用率。•halfwordVM减少64位机器上的内存浪费。•开启HipeJit功能,同时用native方式编译库和应用。•尽量使用binary，最贴近机器内存模型，cache友好。•hipe内置的未公开的bif•进程字典•留意你的进程的最大文件句柄数,太大会浪费很多资源。•留意你的IO需要的异步线程。Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论推荐的性能调优工具操作系统层面的：•systemtap•oprofile•blktrace•tsung•gdb•lmbenchErlang平台上的：•lcnt•dialyzer•内置的自省机制•cerl了解IO系统性能测试工具：•Fio测试多种IO的效率(sync,mmap,libaio,posixaio...)•Sysbench简单易用的测试工具•Iozone侧重文件系统以及应用的数据访问模式IO监视工具•Blktrace•btt可视化你的IO活动•seekwatcher可视化你的磁头移动其他工具•slabtopss用于统计大量socket占用的资源情况netstat之类的工具对于大量的链接来讲实在太慢！了！Systemtap帮助你了解你的程序Agenda•硬件层面变化和思考•操作系统层面变化和思考•语言和库层面变化和思考•Erlang平台层面变化和思考•调优工具•结论结论•C1000K离我们很近的，几年后技术就会普及。•C1000K是个渐近的过程，点滴成就高性能。•C1000K需要软硬件技术的高度配合，需要关心的层次很深,是个系统工程。•C1000K随着应用和构造工具的不同，难道也变化的很大。•C1000K用Erlang平台构造最不痛苦（个人感觉）。祝大家C1000K的开心！谢谢大家！Anyquestion？大部分的图片粘贴自Google搜索的文档，谢谢Google，谢谢这些可爱的作者。