C1000K高性能服务器构建技术
Download as PPT, PDF170 likes9,828 views
文档探讨了 c1000k 高性能服务器构建的技术挑战，尤其是 c10k 问题的延续，以及如何通过硬件和操作系统的并行化来满足不断提升的服务响应时间和可靠性要求。作者分析了包括 CPU、内存、网络和存储等多层次的硬件变化，以及在 Erlang 平台上进行高效调度和优化的经验。最后，强调 c1000k 是一个系统工程，需要技术的高效配合和深入的关注。
![C1000K 高性能服务器构建技术 余锋 http://yufeng.info [email_address] 淘宝网核心系统资深专家 2010/10/16](https://image.slidesharecdn.com/c1000k-12871244425597-phpapp01/85/C1000K-1-320.jpg)
![中断平衡 硬中断 : irqbalance 智能的均衡硬件中断。 手动 [root@linux /]#echo ff > /proc/irq/19/smp_affinity 软中断 :](https://image.slidesharecdn.com/c1000k-12871244425597-phpapp01/85/C1000K-17-320.jpg)
![来自 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](https://image.slidesharecdn.com/c1000k-12871244425597-phpapp01/85/C1000K-20-320.jpg)
![列表 [] 数据结构 Erlang 的 [] 注意事项： 1. 单链表，只能表头访问，数据分散， 特别是数据被 GC 过后，中间的洞变大，对 cache 很不友好。 2. Erlang 的 IO 支持 iolist, 底层会用 writev 发送数据，尽量用 iolist.](https://image.slidesharecdn.com/c1000k-12871244425597-phpapp01/85/C1000K-29-320.jpg)
C1000K高性能服务器构建技术
- 1. C1000K 高性能服务器构建技术 余锋 http://yufeng.info [email_address] 淘宝网核心系统资深专家 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, 24G 内存， 640G SAS
- 3. 解决方案 顺应硬件和操作系统的变化方向， 高度并行化 应用！让 独立的 网卡， 独立的 CPU 核心， 独立的 cache, 独立的 本地内存， 独立的 (soft)IRQ ， 独立的 Erlang 调度器， 独立的 Erlang 进程服务你的每个 独立的 请求 ! 图 ! 图 ! 图 !
- 4. Agenda 硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang 平台层面变化和思考 调优工具 结论
- 5. Dell R710 机器
- 6. 硬件体系巨大变化 现在 过去 北桥慢慢成为过去！
- 7. Cache 在现代 CPU 硬件上的版面， 也充分说明了 cache 的重要性
- 9. Virident pci-e 卡 IOPS 高达 200K ，带宽 800M
- 10. 小结 硬件变得和过去很不一样，性能越来越高。 硬件从 CPU ，内存，网卡都在试图 scale ， 我们要配合硬件的并行化趋势。 硬件在 cache 方面下了很多血本，提高数据的 locality 。 采用合适的硬件，比如说 ssd 盘代替 sas 盘。
- 11. Agenda 硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang 平台层面变化和思考 调优工具 结论
- 12. 深度调查系统，为设计做 依据
- 13. Numa 架构下的调度器， CPU 亲缘性
- 14. Numa matters google 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 的 unbreakable 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 。 合并你的数据，一次写入，页面是 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 内存分配池 Numa aware 何时支持？ R14B ？ largepage 何时支持？ 内部有几百个分门别类的内存池。 mseg_alloc ： 通过 mmap 来向系统申请内存，批发给其他内存分配池。 每个调度器自己的内存池。
- 37. Erlang 进程和 Port 进程和现实世界 1:1 映射。 进程是根据时间片实现抢占式公平调度。 每个进程独立的堆和栈，独立的进行 GC, 消息通过拷贝的方式传递。 Tcp port 也是和现实世界 1 ： 1 映射。 Port 通过 Kernel Poll 来实现事件监测 ， IO 调动独立于进程调度，也是公平调度。 每个 tcp port 内部都有发送队列（高低水位线），以及接受缓冲区。 port 和进程的 slot 位都是预先分配好的。
- 38. Erlang 进程单点 /race 问题 已知有单点的模块： x y 已知有 race 的模块 ets mnesia erlang:register/unregister 日志系统： 内置的太慢，推荐自己用 linux shm 来实现个 ring buf 。
- 39. Erlang NIF R14 新添加的，丰富的接口，容易用 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. Mnesia OTP 最核心的部件 Mnesia ，是做分布式系统最关键的一环！
- 42. 小结 并行化进程，按照 1:1 映射到现实世界。 Erlang 的调度器绑定，提高 cach 的利用率。 halfword VM 减少 64 位机器上的内存浪费。 开启 Hipe Jit 功能 , 同时用 native 方式编译库和应用。 尽量使用 binary ，最贴近机器内存模型， cache 友好。 hipe 内置的未公开的 bif 进程字典 留意你的进程的最大文件句柄数 , 太大会 浪费 很多资源。 留意你的 IO 需要的异步线程。
- 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 之类的工具对于大量的链接来讲实在太慢！了！
- 49. Agenda 硬件层面变化和思考 操作系统层面变化和思考 语言和库层面变化和思考 Erlang 平台层面变化和思考 调优工具 结论
- 50. 结论 C1000K 离我们很近的，几年后技术就会普及。 C1000K 是个渐近的过程，点滴成就高性能。 C1000K 需要软硬件技术的高度配合，需要关心的层次很深 , 是个系统工程。 C1000K 随着应用和构造工具的不同，难道也变化的很大。 C1000K 用 Erlang 平台构造最不痛苦（个人感觉）。 祝大家 C1000K 的开心！
- 51. 谢谢大家！ Any question ？ 大部分的图片粘贴自 Google 搜索的文档，谢谢 Google ，谢谢这些可爱的作者。
Editor's Notes
- #13: 宝宝宝宝宝