Glusterfs目录ls性能优化方案分析

Glusterfs目录ls性能优化方案分析

目的和优化思路

讨论了glusterfs对文件系统爬虫rsync/ls目录性能的现有优化措施和可能的进一步优化方案。优化思路是减少本地文件系统的元数据操作,减少fuse client的负载,减少req的网络轮询次数,减少一次网络通信时间,缓存预抓取,并发,异步,bulk 传输

fuse readdirplus

centos 6.4最新内核,支持fuse readdirplus。微调mount timeout参数。

readdir-ahead

这个已经合并到3.5release以后了。主要进行了单线程ls顺序目录读的优化。通过在opendir时(在执行回调时)去提前抓取目录项作为缓存,同时也会在glusterfs readdirplus支持(内核和glusterfs fuse都支持)的情况下,抓取目录项的inode属性和扩展属性,readdir(p)时可以直接返回或者此时抓取目录项缓存。基于fuse readdirplus性能会更加优化。基于fd生命周期进行的缓存。功能还很不强大,需要强化。

FUSE_AUTO_INVAL_DATA

根据内核FUSE_AUTO_INVAL_DATA支持,启用--fopen-keep-cache mount选项。 新内核版本支持。glusterfs fuse默认行为是写操作是同步的,读文件操作从page cache中读。当打开一个文件时,失效原来file的page cache。启用此选项后,就可以根据需要,如果原来file page cache 内容没变,就不进行失效操作。

quick-read

glusterfs3.4把quick-read(3.3就这一个translaotr)分解为openbehind和quick-read。原来设计不管操作文件的目的是什么,都要获取真正的fd。重构后,可以根据文件操作目的,如果是修改文件内容,就在背景打开文件并进行操作。如果仅仅是fstat等类似操作,就利用匿名fd来进行,不会等待真正的fd。这样根据操作目的,优化了性能。在lookup时根据需要,设置xdata key,在posix translator层就抓取文件内容。read操作执行到quick-read层时就返回文件内容。

md-cache

主要是inode attr和xattr在readdir (p)时抓取;lookup只抓取当时操作的目录或文件的inode属性,而不是所有目录项。这个translator可以对ls时候对stat和扩展属性抓取导致的延迟进行优化。但目前我们一般关闭selinux和acl扩展属性支持,所以扩展属性的ls优化暂时不起作用。

其他可能影响的translator,有待分析

  • io-threads 服务器和客户端设置
  • libaio
  • scatter-gather IO

进一步的优化方向

  • fuse内核当前支持4k readdir buffer大小。可以修改内核代码支持较大chunk的buffer。readdir-ahead就是用一个glusterfs rpc 128k buffer进行了bulk获取,但也仅仅是在用户空间进行了预抓取。Brian Foster进行了这方面的优化实验。
  • 强化readdir-ahead,做成一个强大的client缓存架构,先做目录项缓存,后面再考虑其他的。
    • 多线程,非顺序目录读的情况
    • 缓存基于inode,进行持久缓存
    • Xavier Hernandez提出了取代inodelk/entrylk的一种无锁架构,有助于在client实现一个强大的缓存。目前社区已经进行了一次讨论缓存架构的头脑风暴。正在跟进。
    • dht读目录本来就是顺序(一个一个brick进行读取),应该分析是否可以放宽这样的限制
  • 小文件合并为大文件的transtlaotr。这个可以参考hystack和tfs的实现。
  • 参考hdfs的中央缓存架构,不在client做真正的缓存,而在brick端缓存,client只做路由。或者client和brick都做缓存。
  • 分层存储。这个glusters 已经在开始做了。

参考资料

gluster maillist,irc,code,review。


Last updated 2014-05-02 14:01:32 CST

Glusterfs目录ls性能优化方案分析

时间: 2024-11-05 13:52:24

Glusterfs目录ls性能优化方案分析的相关文章

Android 应用开发性能优化完全分析

1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质博文网上也还是有很多的,譬如Google官方都已经推出了优化专题,我这里只是总结下自的感悟而已,若有得罪欢迎拍砖,我

【转】Android应用开发性能优化完全分析

http://blog.csdn.net/yanbober/article/details/48394201 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质博文网

GNU Linux高并发性能优化方案

/*********************************************************** * Author : Samson * Date : 07/14/2015 * Test platform: * gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 * GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu) * Nginx version: * Nginx 1.6.2 * Nginx 1.8.0

转——Android应用开发性能优化完全分析

[工匠若水 http://blog.csdn.net/yanbober 转载请注明出处.] 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质博文网上也还是有很多的,

转:Android应用开发性能优化完全分析

转自:http://blog.csdn.net/yanbober/article/details/48394201 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质

Redmine性能优化方案

近来公司redmine服务器表现很糟糕,在16核,64GRAM的机器上,压测结果竟然只有每秒5~7个请求,部分页面一个都出不来. 以下是我对Redmine性能优化方案: redmine服务器性能问题排查与优化建议: 以下建议的方案是基于redmine运行期的log文件中的render耗时.activerecord耗时,linux系统性能指标采样与 mysql 性能指标采样分析,以及redmine在不同web server下的benchmark而得:   一. 问题排查与定量分析 通过分析redm

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP

mysql 性能优化方案

这是一篇关于mysql 性能优化的文章.网上有不少mysql 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用status信息对mysql进行具体的优化. mysql> show global status; 可以列出MySQL服务器运行各种状态值,另外,查询MySQL服务器配置信息语句:mysql> sho