影响服务器性能的四大杀手

经得住诱惑 · 发表于 2016-3-22 11:35:45

数据拷贝（Data Copies）

　　几乎每个大学课程和几乎所有how-to文档中都提到了它。甚至在某些商业宣传册中，”零拷贝” 都是个流行用语。

　　尽管数据拷贝的坏处显而易见，但是还是会有人忽视它。因为产生数据拷贝的代码常常隐藏很深且带有伪装，你知道你所调用的库或驱动的代码会进行数据拷贝吗？答案往往超出想象。猜猜“程序I/O”在计算机上到底指什么？哈希函数是伪装的数据拷贝的例子，它有带拷贝的内存访问消耗和更多的计算。曾经指出哈希算法是一种有效的“拷贝+”似乎能够被避免，但据我所知，有一些非常聪明的人说过要做到这一点是相当困难的。如果想真正去除数据拷贝，不管是因为影响了服务器性能，还是想在黑客大会上展示”零复制”技术，你必须自己跟踪可能发生数据拷贝的所有地方，而不是轻信宣传。
　现在，代码可以简单的在相应的描述符上增加引用计数来代替内存中数据的拷贝。这种做法在某些条件下表现的相当好，包括在典型的网络协议栈的操作上，但有些情况下这做法也令人很头大。一般来说，在buffer chains的开头和结尾增加buffer很容易，对整个buffer增加引用计数，以及对buffer chains的即刻释放也很容易。在chains的中间增加buffer，一块一块的释放buffer，或者对部分buffer增加引用技术则比较困难。而分割，组合chains会让人立马崩溃。
上下文切换（Context Switches）

　　相对于数据拷贝影响的明显，非常多的人会忽视了上下文切换对性能的影响。在我的经验里，比起数据拷贝，上下文切换是让高负载应用彻底完蛋的真正杀手。

　　一个有适量线程的程序首先要考虑的事情是规划出如何创建一个线程去管理多连接。这通常意味着前置一个select/poll, 异步I/O，信号或者完成端口，而后台使用一个事件驱动的程序框架。关于哪种前置API是最好的有很多争论。 Dan Kegel的C10K在这个领域是一篇不错的论文。个人认为，select/poll和信号通常是一种丑陋的方案，因此我更倾向于使用AIO或者完成端口，但是实际上它并不会好太多。也许除了select()，它们都还不错。所以不要花太多精力去探索前置系统最外层内部到底发生了什么。

　　对于最简单的多线程事件驱动服务器的概念模型, 其内部有一个请求缓存队列，客户端请求被一个或者多个监听线程获取后放到队列里，然后一个或者多个工作线程从队列里面取出请求并处理。从概念上来说，这是一个很好的模型，有很多用这种方式来实现他们的代码。这会产生什么问题吗？引起环境切换的第二个原因是把对请求的处理从一个线程转移到另一个线程。有些人甚至把对请求的回应又切换回最初的线程去做，这真是雪上加霜，因为每一个请求至少引起了2次环境切换。把一个请求从监听线程转换到成工作线程，又转换回监听线程的过程中，使用一种“平滑”的方法来避免环境切换是非常重要的。此时，是否把连接请求分配到多个线程，或者让所有线程依次作为监听线程来服务每个连接请求，反而不重要了。

　　即使在将来,也不可能有办法知道在服务器中同一时刻会有多少激活线程.毕竟，每时每刻都可能有请求从任意连接发送过来，一些进行特殊任务的“后台”线程也会在任意时刻被唤醒。那么如果你不知道当前有多少线程是激活的，又怎么能够限制激活线程的数量呢？根据我的经验，最简单同时也是最有效的方法之一是：用一个老式的带计数的信号量，每一个线程执行的时候就先持有信号量。如果信号量已经到了最大值，那些处于监听模式的线程被唤醒的时候可能会有一次额外的环境切换,(监听线程被唤醒是因为有连接请求到来, 此时监听线程持有信号量时发现信号量已满,所以即刻休眠), 接着它就会被阻塞在这个信号量上，一旦所有监听模式的线程都这样阻塞住了，那么它们就不会再竞争资源了，直到其中一个线程释放信号量，这样环境切换对系统的影响就可以忽略不计。更主要的是，这种方法使大部分时间处于休眠状态的线程避免在激活线程数中占用一个位置，这种方式比其它的替代方案更优雅。

内存分配（Memory Allocator）

　　申请和释放内存是应用程序中最常见的操作, 因此发明了许多聪明的技巧使得内存的申请效率更高。然而再聪明的方法也不能弥补这种事实:在很多场合中，一般的内存分配方法非常没有效率。所以为了减少向系统申请内存，我有三个建议。

　　建议一是使用预分配。我们都知道由于使用静态分配而对程序的功能加上人为限制是一种糟糕的设计。但是还是有许多其它很不错的预分配方案。通常认为，通过系统一次性分配内存要比分开几次分配要好，即使这样做在程序中浪费了某些内存。如果能够确定在程序中会有几项内存使用，在程序启动时预分配就是一个合理的选择。即使不能确定，在开始时为请求句柄预分配可能需要的所有内存也比在每次需要一点的时候才分配要好。通过系统一次性连续分配多项内存还能极大减少错误处理代码。在内存比较紧张时，预分配可能不是一个好的选择，但是除非面对最极端的系统环境，否则预分配都是一个稳赚不赔的选择。

　　建议二是使用一个内存释放分配的lookaside list(监视列表或者后备列表)。基本的概念是把最近释放的对象放到链表里而不是真的释放它，当不久再次需要该对象时，直接从链表上取下来用，不用通过系统来分配。使用lookaside list的一个额外好处是可以避免复杂对象的初始化和清理.

　　第三条建议与我们还没有讨论的锁有关系。先抛开它不说。即使使用lookaside list,内存分配时的锁竞争也常常是最大的开销。解决方法是使用线程私有的lookasid list, 这样就可以避免多个线程之间的竞争。更进一步，每个处理器一个链会更好，但这样只有在非抢先式线程环境下才有用。基于极端考虑，私有lookaside list甚至可以和一个共用的链工作结合起来使用。

锁竞争（Lock Contention）

　　高效率的锁是非常难规划的, 以至于我把它称作卡律布狄斯和斯库拉(参见附录)。一方面, 锁的简单化(粗粒度锁)会导致并行处理的串行化,因而降低了并发的效率和系统可伸缩性; 另一方面, 锁的复杂化(细粒度锁)在空间占用上和操作时的时间消耗上都可能产生对性能的侵蚀。偏向于粗粒度锁会有死锁发生，而偏向于细粒度锁则会产生竞争。在这两者之间，有一个狭小的路径通向正确性和高效率，但是路在哪里？

　
文章来源于：主机论坛：http://bbs.cuwww.com/forum.php 转载请注明出处