登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

SeaRiver Blog

实力才是你一生最好的依靠!

 
 
 

日志

 
 

NFS缓存IO机制  

2014-01-14 16:46:14|  分类: nfs |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

NFS的缓存IO机制

<一> async 参数模式下分析

   NFS 默认的mount参数为async,async 参数表示内核不会透传程序的IO请求给sever,对于写IO会延迟执行,积累一定的时间以便合并上层的IO请求以提高效率。

  • 读分析

    1: 顺序读请求的合并预读

        dd   if=/mnt/nfs/3  of=/dev/null   bs=1500 count=100

        测试发现仅仅发送了6个read请求     16384 + 32768 * 4 + 2544 =150000,并且其中后5个请求是连续发送的。        

    2:随机读读惩罚

        随机读情况下,由于都有预读,所有每次预读都会多读一部分数据,导致可能实际使用的数据量不到接受到数据的10分之一,称为读惩罚。

  • 写分析

    1:追加写

        dd  if=/dev/zero  of=/mnt/nfs/ddtest  bs=1 count=100

        dd将已经存在的文件的size(SETATTR)设置为0,然后从头开始追加写入这个文件,每次写1B,写100次。但是内核并没有像NFS服务器发送100次写,实际上指发送了一次写。

    2:覆盖写

        连续覆盖写:内核行为和追加写一样,内核对写操作进行了合并。

        随机覆盖小:随机模式下,内核无法对写进行合并,直接完全透传用户程序发起的I/O。

<二> sync参数模式下的分析

  • 读分析

    1:如果mount的时候选用sync参数,或者如果上层使用 sync 调用,那么其产生的读I/O一定在内核处也是同步的,因为只有在前一个读请求数据成功返回给客户端程序,客户端程序才会发起下一个读请求,(对于异步读调用,内核可以在短时间内接受到多个读请求,此时内核可以将这些读请求合并,这就是异步过程)。但是同步读并不影响nfs的预读,比如

dd  if=/mnt/nfs/ddtest    bs=1 count=150,并不是向server发送150个一次1B的请求,而是根据rsize进行预读,把150B的数据一次性读回来,其他159次就直接命中缓存了。

  • 写分析

     1:对于sync同步的写调用,程序只有在第一个写调用结束之后才会发起下一个写。

       dd  if=/dev/zero   of=/mnt/nfs/ddtest    bs=1  count=1500 (1B为单位的写操作),那么就是发送150个write请求,效率非常低下。

 

     注意:DIO模式由于每次都绕过了内核的pagecache ,所以每一个请求都会向服务端发起请求,不会进行预读,异步写,写合并,读合并等策略。

 

  评论这张
 
阅读(633)| 评论(0)

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018