转】关于高吞吐量下的内存和磁盘处理

当前是互联网70%以上的带宽全部被音视频给吃掉了，随着网络基础的提升，终端的带宽越来越大，

面临大用户的情况下，后端服务器的吞吐量将大大增加，服务端程序对于内存和磁盘io的处理以及降低cpu消耗是必须跨越的门槛。

   传说中的zero copy。当前主流的操作系统来说，读取设备上的数据都涉及到内核空间和用户空间的数据交换和系统调用，这是非常昂贵的操作，大量的消耗cpu的时钟。拿linux来说，zero copy最典型的例子是apache 在发送大文件时使用的sendfile调用，直接在内核层完成文件到网络的发送，不涉及到copy到用户层然后，然后再copy回内核层发送的问题，这样反复copy两次，多次的访存，直接导致低效。

  zero copy 并不适用于大多数情况，很多时候数据需要经过处理或者获取某些信息后再发送出去，所以最少存在于应用层一次copy，原理上一次就够了，只要在整块连续内存中没有插入操作或者极少的插入操作基本都不用copy，如果有额外的数据就在适当的时候在发送时发送即可，不必进行大量的内存移动。

  基本得出一条原则：内存尽量减少访问和copy次数，数据量再小，在极高的频率下产生极大的消耗。

 

  大多数情况内存处理不是太低效一般不会成为性能瓶颈，大多数问题出在磁盘。为了充分利用磁盘的性能，操作系统层面上有不少的cache，数据的cache，读取指令队列cache；硬件上Raid卡cache，磁盘内部突发cache等等。

   对于机械盘来讲，磁盘数据的读写熟读与所访问数据在磁盘上的分布是否连续有极大的关系，关于写数据，如果事先知道文件大小，最后一次性将文件空间分配完毕，尽量保证连续的空间，为后期的读效率做好准备，同时连续文件对与同文件写同样有这高效的表现。如果在时间不紧要的情况下将写操作序列化掉。

   同时注意调整各个cache的大小，需要结合实际应用和数据的读写大小和频率，随机程度等综合考虑，以实际测试为准。

   可以使用系统和硬件提供的便利的，尽量减少应用层的复杂度，复杂基本是低效的代名词，强复杂性和耦合性是调优的最大障碍，设计之初要考虑巨大数据量的吞吐问题。