FastDFS 5.04之IO读事件空转导致CPU空转

在与同事测试FastDFS过程中发现CPU有异常波动的情况，八核心CPU在系统使用同时达到%60以上，不免诧异，遂对代码进行排查，发现storage有如下两个问题：

1）CPU短暂地飙升

2）特定的情况下，可以导致CPU永久飙升，直到停止程序

这两个问题都是由于IO读事件空转导致。

IO读事件空转也就是epoll触发了一个读事件，调用相应地处理函数，而该处理函数什么事情也不干就返回了，由于事件触发条件还在，因此调用epoll_wait后再次触发，如此反复，CPU消耗在了系统调用上。

注：作者已经修改了第二个问题，第一个问题作者暂时还没有修改。关于第二个问题只要更新作者提供的最新libcommon代码即可。

一、CPU短暂地飙升

为了方便理解，此处载录少量关键代码。

1、读取网络数据处理函数 client_sock_read

FastDFS中每个连接对应一个任务，每个任务自带缓冲区，默认为256KB，当一个客户端Upload的文件的大小若为1MB，那么就需要分4次读到缓冲区，每次缓冲区读满需要将该任务提交给磁盘线程（DIO），由磁盘线程将缓冲区内容写入到文件之后，再次读取后面的内容，如此反复直到整个请求包读取完成。

此处定义package为一个缓冲区大小，256KB，request为一次请求大小，1MB。

void client_sock_read(int sock,short event, void* arg){
        ///从参数中提取任务
<span style="white-space:pre">	</span>struct fast_task_info *pTask = (structfast_task_info *)arg;
<span style="white-space:pre">	</span>StorageClientInfo*pClientInfo = (StorageClientInfo*)pTask->arg;

<span style="color:#cc0000;">        ///判断任务的状态，若状态非RECV则直接返回，不做任何处理，导致空转
</span><span style="white-space:pre">	</span>if(pClientInfo->stage!= FDFS_STORAGE_STAGE_NIO_RECV){return;}

        ///读取网络数据报
        while(1){
             bytes = recv(…)
             if(bytes < =0){
               ……
               break;
             }

             if(package recv done)  ///一个缓冲区读取完成
 <span style="white-space:pre">		</span>{ 
                 if(reqeust recv done){   ///一次请求读取完成，改变状态为SEND
                   pClientInfo->stage = FDFS_STORAGE_STAGE_NIO_SEND;
                 }
            
                 ///push into dio thread queue
                storage_dio_queue_push(pTask);
                return;
<span style="white-space:pre">		</span>}
     }
}

接着我们来看下任务添加到磁盘IO线程的代码，如下，注意在其中改变了任务状态。

intstorage_dio_queue_push(structfast_task_info *pTask){
<span style="color:#cc0000;">     ///设置任务状态为IO处理中
     pClientInfo->stage|= FDFS_STORAGE_STAGE_DIO_THREAD;
</span>
     ///将任务添加到磁盘IO处理线程同步队列
     result=task_queue_push(&(pContext->queue), pTask);

     ///使用条件变量通知磁盘IO线程有任务到达
     result=pthread_cond_signal(&(pContext->cond));
}

让我们来分析下，epoll有两种工作方式，分别是水平触发与边缘触发。FastDFS中使用epoll的水平触发工作方式。

还是以客户端Upload一个1MB文件，缓冲区为256KB为例：

1）storage服务器通过client_sock_read函数不断从网络中读取数据，直到一个缓冲区读满了，这时候需要将任务交给磁盘线程处理。

2）调用 storage_dio_queue_push函数将任务加入到磁盘处理队列，在其中会设置任务状态为 |=  FDFS_STORAGE_STAGE_DIO_THREAD

3）client_sock_read函数返回（ 注意，代码中并没有将该FD从epoll事件监听列表中清除）

4）假如此时该socket之中还有数据，或者客户端关闭该socket，该socket都将会继续触发读事件，问题来了，读事件的处理函数中

只有任务状态为RECV才会处理，因此直接返回。再次调用epoll_wait时，马上又会触发该事件，如此反复，CPU都消耗在了epoll_wait的系统调用上。

     同样地，当读取完成1MB的数据之后，client_sock_read函数先将任务状态设置成SEND，然后将任务提交给磁盘IO处理线程，在磁盘IO线程处理完成该任务之前，都存在读事件空转的可能。

     改进方法：将任务提交给磁盘IO处理线程成功后，应该将该socket从epoll监听列表中清除，待磁盘处理完成后再添加到epoll监听列表之中。

2、网络写入函数，client_sock_write函数，该函数实现将数据发送给客户端，比如客户端要下载一个文件时。

根据之前的介绍，每个任务都自带缓冲区，默认256KB，若下载一个1MB的文件，那么每次只能读取256KB的内容到缓冲区，然后发送缓冲区内容给客户端，如此需要重复4次才能发送完成。

注意：在触发该函数之前任务的状态为 FDFS_STORAGE_STAGE_NIO_SEND；

voidclient_sock_write(intsock,shortevent,void*arg){
        ///从参数中提取任务
<span style="white-space:pre">	</span>struct fast_task_info *pTask = (structfast_task_info *)arg;
       StorageClientInfo*pClientInfo = (StorageClientInfo*)pTask->arg;

        ///读取网络数据报
        while(1){
             bytes = send(…)
             if(bytes <= 0){
               ……..
               break;
             }

             if(package send done)  ///一个缓冲区写入完成
     <span style="white-space:pre">	</span>     {
                 set_recv_event(pTask);   ///将当前监听写事件修改成监听读事件
                 if(reqeust send done){   ///一次请求写入完成，改变状态为RECV
                   pClientInfo->stage = FDFS_STORAGE_STAGE_NIO_RECV;
                 }
            
                 ///push into dio thread queue
                storage_dio_queue_push(pTask);
                return;
     <span style="white-space:pre">	</span>    }
     }
}

看出问题所在了么，write函数将一个缓冲区写入到socket之后，设置了读事件监听，然后将任务提交给磁盘IO处理线程。由于此时该任务的状态为SEND，而读事件的处理函数client_sock_read只有在任务状态为RECV才处理，这里又存在读事件空转的可能性了。那么这种可能性是什么呢？也就是什么时候会变成可读，那就是当客户端关闭时，该socket就变成可读。

上述说明的两点还不算太坏，因为空转是短暂的，只要磁盘线程处理完成任务，空转就会停止，但是我下面要说的一点是，空转永远不会停止的。由于FastDFS代码中的BUG，导致有些任务添加到磁盘处理队列后丢失，该任务永远不会被磁盘线程处理到，那么就会停留在空转上。只要这个条件触发，即使把所有客户端都关闭也不能停止CPU的空转。

二、关于磁盘处理队列任务丢失

     1、在FastDFS之中，为每个客户端socket连接分配一个Task,每次分配一块大内存，然后在其中分割出多个Task。如下图：

     全局的g_mpool是内存块的链表，由于当前只有一个内存块，因此head、tail都指向该块。

     同时这些任务被分配使用后，每个client上有不同的请求，假定某一个时刻的磁盘处理线程任务队列如下图，T1->T4->T2->T3;

     当有新的客户端连接上来时，由于已经分配的Task已经用完，就需要分配第二块大内存来构造出新的Task，此时程序分配了第二块内存,分割成T5、T6、T7、T8，此时作者将第一块内存的最后一个Task->next连接到第二块内存的第一个Task，也就是将T4->next = T5.

     为何这么做是有问题的呢？请看当前状态的dio_queue，T4->next = T2; 当被执行了T4->next = T5之后，原本属于dio_queue中的T2、T3失联了，那么这两个任务就永远不会被磁盘线程处理到，接下来，不用我说了，只要在这两个socket上发生空转，就是永久的。