FastDFS（提升磁盘IO性能的几个技巧& FastDFS 5.04之IO读事件）

最新推荐文章于 2021-07-19 09:58:06 发布

z荒野求生

最新推荐文章于 2021-07-19 09:58:06 发布

阅读量1k

点赞数 1

分类专栏：公有云-华为能力建设配置笔记

原文链接：https://blog.csdn.net/hfty290/article/details/41257555

版权

配置笔记同时被 3 个专栏收录

420 篇文章 20 订阅

订阅专栏

能力建设

195 篇文章 12 订阅

订阅专栏

公有云-华为

109 篇文章 10 订阅

订阅专栏

提升磁盘IO性能的几个技巧

https://www.cnblogs.com/derekchen/archive/2012/04/04/2431573.html

目前磁盘都是机械方式运作的，主要体现在磁盘读写前寻找磁道的过程。磁盘自带的读写缓存大小，对于磁盘读写速度至关重要。读写速度快的磁盘，通常都带有较大的读写缓存。磁盘的寻道过程是机械方式，决定了其随机读写速度将明显低于顺序读写。在我们做系统设计和实现时，需要考虑到磁盘的这一特性。

　　FastDFS是一个开源的高效分布式文件系统，它最初的实现，文件是按hash方式随机分布到多个目录中的，后来增加了顺序存放的做法。通过对比测试，发现文件按目录顺序存储，写文件IO效率明显高于按目录随机存储。

　　目前磁盘顺序读取的速度并不差，比如普通硬盘的IO可以达到每秒40~60MB，好一些的硬盘可以达到每秒100MB左右。在多进程或多线程并发读取磁盘的情况下，随着并发数的增加，磁盘IO效率将大大下降。主要是因为每次读写，磁道可能存在较大的偏移，磁道寻址时间加大，导致磁盘IO性能急剧下降。对于这种场景，优化方案是尽可能减少并发读写的进程数或线程数。可以用锁的机制，也可以采用专门的磁盘IO线程来对磁盘进行读写。FastDFS 2.x版本，磁盘读写就采用了专门的线程来完成。

　　为了充分发挥多块磁盘的效率，不建议使用传统的RAID方式。比较好的做法是每块磁盘单独mount，通过程序来控制对多块磁盘进行并发读写。采用单盘mount，文件的备份和冗余可以通过多台机器实现。

　　文件数多了之后，比如达到上千万个文件，当随机访问众多文件时，文件系统的性能会急剧下降。业界流行的做法是将多个小文件合并存储到一个大文件中的方式来降低文件数。FastDFS 3.0支持将多个小文件合并存储到一个较大文件中，目前开发进展比较顺利，预计5月份可以发布3.0版本。

　　提升磁盘IO的另外一个技巧，一次尽可能多写入或多读取。也就是说，将程序的读写buffer设置得尽可能大一些。例如日志或者redo log的写入，不是每次调用都直接写磁盘，而是先缓存到内存中，等buffer满了再写入磁盘，也可以定时写入磁盘。

　　操作系统和C库函数通常会对写入的文件内容做缓存，以减少实际写文件的次数。直接调用系统函数fsync或C函数fflush将使系统的缓存机制失效，此时将强制把内容刷到磁盘上。除非必需，否则不要执行强制刷盘操作。

　　注：如果没有特别说明，文中说的磁盘指的是硬盘。

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

https://blog.csdn.net/hfty290/article/details/41257555

在与同事测试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){
///从参数中提取任务
 struct fast_task_info *pTask = (structfast_task_info *)arg;
 StorageClientInfo*pClientInfo = (StorageClientInfo*)pTask->arg;
 ///判断任务的状态，若状态非RECV则直接返回，不做任何处理，导致空转
 if(pClientInfo->stage!= FDFS_STORAGE_STAGE_NIO_RECV){return;}
///读取网络数据报
while(1){
bytes = recv(…)
if(bytes < =0){
……
break;
}
if(package recv done) ///一个缓冲区读取完成
 {
if(reqeust recv done){ ///一次请求读取完成，改变状态为SEND
pClientInfo->stage = FDFS_STORAGE_STAGE_NIO_SEND;
}
///push into dio thread queue
storage_dio_queue_push(pTask);
return;
 }
}
}

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

intstorage_dio_queue_push(structfast_task_info *pTask){
 ///设置任务状态为IO处理中
pClientInfo->stage|= FDFS_STORAGE_STAGE_DIO_THREAD;

///将任务添加到磁盘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){
///从参数中提取任务
 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) ///一个缓冲区写入完成
 {
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;
 }
}
}

看出问题所在了么，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;