对于做大量并发服务器端（比如Web服务器Nginx、Apache等）开发的童鞋，肯定知道有一个名为C10K的问题。当然，这是一个比较古老的问题了，从03年（非准确值）提及到现在已经有10余年之久。而随着整个网络相关技术的高速发展，包括CPU、网卡、操作系统等，人们对业务需求所追求的并发连接性能也从10K提升到10M级别，即所谓的C10M问题。这个问题的初次提及到现在应该还没多久，大概也就是2013年上半年的事情，本文就来具体看看其相关内容。
相比以前，现在的硬件很便宜，1200美元可以买一台8核CPU、64GB和带有固态硬盘以及10G万兆网卡的通用电脑。这种通用电脑的性能很高，足够充当各种网络服务设备，因此很多看似贴有服务器专用标签的网络设备，揭开标签纸之后，就是一台普普通通的个人通用电脑。
硬件不是10M问题的性能瓶颈所在处，真正的问题出在软件上，尤其是*nux操作系统。这里有几点：
首先，最初的设计是让Unix成为一个电话网络的控制系统，而不是成为一个服务器操作系统。对于控制系统而言，针对的主要目标是用户和任务，而并没有针对作为协助功能的数据处理做特别设计，也就是既没有所谓的快速路径、慢速路径，也没有各种数据服务处理的优先级差别。
其次，传统的CPU，因为只有一个核，操作系统代码以多线程或多任务的形式来提升整体性能。而现在，4核、8核、32核、64核和100核，都已经是真实存在的CPU芯片，如何提高多核的性能可扩展性，是一个必须面对的问题。比如让同一任务分割在多个核心上执行，以避免CPU的空闲浪费，当然，这里面要解决的技术点有任务分割、任务同步和异步等。
再次，核心缓存大小与内存速度是一个关键问题。现在，内存已经变得非常的便宜，随便一台普通的笔记本电脑，内存至少也就是4G以上，高端服务器的内存上24G那是相当的平常。但是，内存的访问速度仍然很慢，CPU访问一次内存需要约60~100纳秒，相比很久以前的内存访问速度，这基本没有增长多少。对于在一个带有1GHZ主频CPU的电脑硬件里，如果要实现10M性能，那么平均每一个包只有100纳秒，如果存在两次CPU访问内存，那么10M性能就达不到了。核心缓存，也就是CPU L1/L2/LL Cache，虽然访问速度会快些，但大小仍然不够，我之前接触到的高端至强，LLC容量大小貌似也就是12M。
解决这些问题的关键在于如何将功能逻辑做好恰当的划分，比如专门负责控制逻辑的控制面和专门负责数据逻辑的数据面。数据面专门负责数据的处理，属于资源消耗的主要因素，压力巨大，而相比如此，控制面只负责一些偶尔才有非业务逻辑，比如与外部用户的交互、信息的统计等等。我之前接触过几种网络数据处理框架，比如DPDK、6wind、windriver，它们都针对Linux系统做了特别的补充设计，增加了数据面、快速路径等等特性，其性能的提升自然是相当巨大。
看一下这些框架的共同特点：
1，数据包直接传递到业务逻辑，而不是经过Linux内核协议栈。这是很明显的事情，因为我们知道，Linux协议栈是复杂和繁琐的，数据包经过它无非会导致性能的巨大下降，并且会占用大量的内存资源，之前有同事测试过，Linux内核要吃掉2.5KB内存/socket。我研究过很长一段时间的DPDK源码，其提供的82576和82599网卡驱动就直接运行在应用层，将接管网卡收到的数据包直接传递到应用层的业务逻辑里进行处理，而无需经过Linux内核协议栈。当然，发往本服务器的非业务逻辑数据包还是要经过Linux内核协议栈的，比如用户的SSH远程登录操作连接等。
2，多线程的核间绑定。一个具有8核心的设备，一般会有1个控制面线程和7个或8个数据面线程，每一个线程绑定到一个处理核心（其中可能会存在一个控制面线程和一个数据面线程都绑定到同一个处理核心的情况）。这样做的好处是最大化核心CACHE利用、实现无锁设计、避免进程切换消耗等等
3，内存是另外一个核心要素，常见的内存池设计必须在这里得以切实应用。有几个考虑点，首先，可以在Linux系统启动时把业务所需内存直接预留出来，脱离Linux内核的管理。第二，Linux一般采用4K每页，而我们可以采用更大内存分页，比如2M，这样能在一定程度上减少地址转换等的性能消耗。
关于这些，也许可以参考下DPDK的源代码，目前DPDK已经完全开源并且可以网络下载了。
完全参考：
1，http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html
2，http://c10m.robertgraham.com/p/blog-page.html
相关文章
转载请注明：爱开源 » *nux平台上的C10M问题