GlusterFS小文件应用调优

信息革命方兴未艾，随着个人和各种组织机构对信息需求的快速增长，数据呈现爆炸式地增长。其中海量小文件的存储场景越来越多，成为了行业的关注重点。业界也有多个针对小文件场景进行优化的分布式文件系统。例如Facebook推出的Haystack，淘宝的TFS等。海量小文件是非结构化数据存储的巨大挑战，GlusterFS独特的无中心架构和弹性哈希算法，非常适合大文件带宽型应用场景，然而面对小文件应用并无显著优势。我们针对海量小文件场景给出GlusterFS系统级调优方法和实践，但要彻底解决小文件问题还是需要存储架构和算法的突破和创新。

1. 问题概述
海量小文件，通常指文件数量达到千万级、亿级、十亿级以上的场景，这种应用场景对元数据读写、存储效率等要求较高，海量小文件（LOSF，lots of small files）是当前业界的一大难题。通常认为文件大小小于1MB的文件为小文件，下面将分析GlusterFS在这种用户场景下的优劣势，以及如何针对该场景进行优化。

2. GlusterFS在海量小文件场景的优势和劣势

GlusterFS系统的metadata跟数据存放在一起，没有像业界的其它分布式文件系统一样采用集中式的metadata服务。这样的架构在海量小文件场景有优势，也有劣势。

• 无中心架构优势1）对于lookup操作，在server端会有最后落盘文件的元数据和分布的缓存，这样在open操作时候可以直接从缓存读取，不需要再操作一次磁盘。而对metadata与data分离的文件系统，lookup在metadata服务上进行，open或者读写时候，需要去读取一次disk查找文件的元数据。
  2） metadata和数据结合紧密，理论上扩展更为线性。添加节点时，该节点的所有metadata都在新增的节点上。
• 无中心架构劣势
  1）在进行类似ls这样的目录遍历相关操作时，由于Gluster没有集中式的metadata服务，需要遍历所有brick相应的目录取出相关的文件列表，导致ls或者find等遍历操作会变成非常慢，这个问题在gluster brick数量多或者文件数量多时候会比较严重。
  2） Gluster在每一个brick节点都建立了隐藏目录.glusterfs，该目录是本机所有的一般文件的硬链接，和目录等文件的软连接。使得Gluster对于后端文件系统的inode数量翻倍。

3.系统优化建议
对于Gluster在小文件场景的优化，可以从硬件和软件两方面进行，如果不考虑成本问题，硬件优化是最为直接有效的优化方法，按照减少数据访问时间的优化思路，采用更高性能的硬件来提高LOSF性能。比如，使用速度更快的SSD作为全部或部分存储介质，部分部署时作为分层存储，可以显著提高随机读写场景下的IOPS/OPS性能；采用处理能力更强或更多的CPU，可以提高系统的I/O处理速度和并发性；配置更大容量的内存，以空间换时间，有效提高数据缓存命中率；采用延迟更小、带宽更高的网络设备优化网络传输效率，比如万兆网络或InfiniBand网络。硬件优化的目标是消除I/O物理通道上的瓶颈，保证理论上的性能最大化，为软件层面的优化工作做铺垫。值得一提的是，硬件设备在性能上要做到匹配，尤其是磁盘和网络，否则容易导致性能瓶颈或者成本浪费。

软件方面，包含系统参数优化和代码层面的优化，代码层面的优化可以考虑增加元数据服务以提升目录遍历相关操作的性能等，系统参数优化包含对Gluster本身和OS系统参数的调优，本文重点介绍软件方面优化的系统参数优化，将从Gluster本身，以及OS上来描述如何针对GlusterFS的海量小文件场景进行性能优化。

3.1.Gluster系统参数调优
3.1.1. event-threads
对文件的元数据执行操作所花费的时间与对其数据执行操作所花费的时间的比率决定了大文件和小文件之间的差异。 元数据密集型工作负载是用于识别此类工作负载的术语。 可以对性能进行一些改进，以优化网络和存储性能，并将Gluster受信任存储池中小文件的吞吐量和响应时间较慢的影响降到最低。

3.1.1.1. 为客户端设置事件线程值
可以通过调整事件线程值来调整Gluster存储服务器的性能。
# gluster volume set VOLNAME client.event-threads <value>
例子：# gluster volume set test-vol client.event-threads 4

3.1.1.2. 为服务器设置事件线程值
可以使用事件线程值来调整Gluster存储服务器的性能。
# gluster volume set VOLNAME server.event-threads <value>
例子：# gluster volume set test-vol server.event-threads 4

线程优化最佳实践
通过调整网络连接处理事件的线程数，可以看到Gluster存储堆栈的性能提升。 以下是调整事件线程值的建议最佳实践。
1.    由于每个线程一次处理一个连接，所以不建议使用比brick进程（glusterfsd）或客户端进程（glusterfs或gfapi）更多的线程连接。 由于这个原因，监视客户端和brick上的连接计数（使用netstat命令）以获得事件线程数的适当数量。
2.    配置比可用处理单元更高的事件线程值可能会再次导致这些线程上下文切换。 推荐将从前一步推导的数目减少到少于可用处理单位的数目。
3.    如果Gluster存储卷在单个节点上运行大量的brick进程，那么减少上一步推导出的事件线程数将有助于竞争进程获得足够的并发性，并避免线程间的上下文切换。
4.    如果某个特定的线程消耗的CPU周期数超过所需的数量，那么增加事件线程数可以提高Gluster存储服务器的性能。
5.    除了推导适当的事件线程计数之外，增加存储节点上的server.outstanding-rpc-limit也可以帮助排队brick进程的请求，而不会让请求在网络队列上空闲。
6.    调整事件线程值时可以提高性能的另一个参数是performance.io-thread-count（及其相关的线程数），可以将其设置为更高的值，因为这些线程在底层文件系统上执行实际的IO操作。

3.1.2.    lookup-optimize
分布式xlator（DHT）在处理查找卷中不存在的条目时会有性能损失。因为DHT会试图在所有子卷中查找文件，所以这种查找代价很高，并且通常会减慢文件的创建速度。 这尤其会影响小文件的性能，其中大量文件被快速连续地添加/创建。 查找卷中不存在的条目的查找扇出行为可以通过在一个均衡过的卷中不进行相同的执行进行优化。
cluster.lookup-optimize配置选项启用DHT查找优化。 要启用此选项，请运行以下命令：
# gluster volume set VOLNAME cluster.lookup-optimize <on/off>
注意：在设置上述选项后，对于新创建的目录配置将立即生效。 对于现有的目录，在DHT对旧目录应用优化之前，需要重新平衡以确保卷处于平衡状态。

3.1.3.    group metadata-cache
启用元数据缓存以提高目录操作的性能。 按照以下顺序从可信存储池上的任意一个节点执行以下命令。
# gluster volume set <volname> group metadata-cache

3.1.4.    performance.parallel-readdir
尽管文件/目录号保持不变，但目录列表的数量会随着卷/块数量的增加而变慢。 通过启用并行readdir卷选项，可以使目录列表的性能与卷中的节点/块的数量无关。因此，卷的增加不会降低目录列表的性能。
执行以下命令启用parallel-readdir选项：
# gluster volume set <VOLNAME> performance.parallel-readdir on
注意：如果卷中的brick超过50个，建议将缓存大小增加到超过10MB（默认值）
# gluster volume set <VOLNAME> performance.rda-cache-limit <CACHE SIZE>

3.1.5.    lookup-unhash
Lookup-unhash配置是在dht上生效的，是指在查找时候，如果在hash所在节点上没有找到相应文件的话，去所有节点上查找一遍。撤销这个配置项，通过如下命令：
# gluster volume set <VOLNAME> lookup-unhashed off

3.1.6.    io-threads
gluster volume set <VOLNAME>  io-thread-count 16
IO线程translator(performance/io-threads）属于性能调整translator的一种，作用是增加IO的并发线程，以提高IO性能。IO线程translator试图增加服务器后台进程对文件元数据读写I/O的处理能力。由于GlusterFS服务是单线程的，使用IO线程translator可以较大的提高性能。
IO线程操作会将读和写操作分成不同的线程。同一时刻存在的总线程是恒定的并且是可以配置的。
注意:  ‘thread-count’ 小于或等于你的CPU数量。

3.1.7.    performance.nfs.read-ahead
基于预设值，read-ahead会顺序地预取一些块。当应用忙于处理一些数据的时候，GlusterFS能够预读下一批等待处理的数据。这样能够使的读取操作更加流畅和迅速。而且，工作起来像一个读的集合器一样（read-aggregator），也就是说，将大量的、零散的读取操作集合成少量的、大一些的读操作，这样，减小了网络和磁盘的负载。page-size 描述了块的大小。page-count 描述了预读块的总数量。
注意：这个translator比较适合于应用在IB-verbs transport环境里。在百兆和千兆以太网接口、没有read-ahead的环境下，能够达到这种连接的最高速度。

3.1.8.    performance.nfs.io-cache
如果在client端被加载，能够帮助减小server的负载（如果client正在读一些文件，而且这个文件在两次读操作期间没有被修改）。举个例子，在编译内核时所需要访问的头文件。

3.1.9.    performance.nfs.quick-read
该选项用来提高小文件读性能。通过网络对文件系统进行操作开销很大，因此，quick-read使用glusterfs内部get接口来一次执行多个posix系统调用open/read/close，一次get调用包含：一个open调用 + 多个read调用 + 一个close调用。

3.1.10.    performance.nfs.stat-prefetch
Stat-prefetch是一个新的性能translator，用于预取目录条目和统计信息。 这个translator的目的是优化像’ls -l’这样的操作，它会在每个目录条目上生成一个目录读取和统计调用。 这样的命令的总体性能现在会更好，因为从缓存的预取统计数据提供目录条目统计数据，而不是触发网络操作来获得该条目的统计信息。

3.1.11.    performance.nfs.io-threads
nfs的io-thread选项，作用与io-thread相同。

3.1.12.    cluster.read-hash-mode
默认值： 1
解释： 在副本卷情况下，这个值如果设置为0则会选择副本中的第一个启动brick读；1 则会根据gfid去选择，这样所有客户端都会选择同一个brick读； 2 是根据 文件gfid和客户端pid 选择副本中的brick，这样当挂载多个客户端则会选择副本中不同的brick。
场景： 在副本卷模式下，多个客户端或者并发请求一个文件时候，选择2可以有概率使多个读请求分散到副本中的不同brick从而提升性能，不局限在磁盘的性能瓶颈上。

3.1.13.    performance.read-ahead-page-count 
默认值：4
解释：预读页的数量
场景：read-ahead 层时候设置预读页数

3.1.14.    network.tcp-window-size 
默认值： null
解释： tcp-window-size client缓存的大小。
场景： 类似tcp-window-size，当缓存区不够，内存足够可以适当调整大小。

3.1.15.    server.outstanding-rpc-limit 
默认值：64
解释：限制客户端rpc 请求数（不限制可能出现内存不足）

3.1.16.    performance.client-io-threads 
默认值：off
解释：并发网络的开启
场景：提高性能

3.1.17.    network.compression
默认值：off
解释：  cdc层功能，在读写文件时候对gzib压缩
场景：  未知

3.1.18.    storage.linux-aio
默认值：off
解释： aio模式，异步非阻塞模式。功能是在posix层read/write 改成 io_prep_pread/io_prep_pwritev 。
场景： 在大量文件时候使用

3.2.    OS系统参数调优
3.2.1.    CPU参数
3.2.1.1. governor
governor的作用是：检测系统的负载状况，然后根据当前的负载，选择出某个可供使用的工作频率，然后把该工作频率传递给cpufreq_driver，完成频率的动态调节。内核默认提供了5种governor供我们使用，分别是：
performance (性能)：强制 CPU 尽可能使用最高的时钟频率；
powersave (省电)：强制 CPU 尽可能使用最低的时钟频率；
ondemand (按需)：系统负载高时，CPU 使用最高的时钟频率；系统空闲时，CPU 使用最低的时钟频率；
userspace (用户态)：允许用户或用户态程序自行设置时钟频率；
conservative (保守)：类似 ondemand，区别是它根据是否适合负载来调整时钟频率，而不是简单的在最高和最低之间选择；

查询可以使用的策略：cpupower –cpu all frequency-info –governors
查询正在使用的策略：cpupower –cpu all frequency-info –policy
设置governor策略：cpupower frequency-set –governor performance

3.2.1.2. energy_perf_bias
该选项选择CPU的能耗和性能偏好策略，共有如下几种策略可供选择：
performance（性能）：处理器不为了节省能源而牺牲性能；
normal（正常）：处理器为了可能明显的节省能源而牺牲较小的性能；
powersave（省电）：处理器为了最有效率的节省能源而接受可能明显的性能减少；

查询energy_perf_bias：x86_energy_perf_policy –r
设置energy_perf_bias：x86_energy_perf_policy performance

3.2.1.3. min_perf_pct
Intel 处理器 P-State（Performance States，性能状态） 的最小值，指最大化性能级别的百分比，通过修改/sys/devices/system/cpu/intel_pstate/min_perf_pct的数值进行控制。

3.2.2.    内存参数
3.2.2.1. transparent_hugepages
Transparent Huge Pages (透明巨页)，内核自动分配巨页给进程，共有如下几种策略可供选择：
always：尝试为任意进程分配巨页
madvise：利用 madvise() 系统调用只为个别进程分配巨页
never：禁用透明巨页

使用如下命令查询设置transparent_hugepages:
查看　cat /sys/kernel/mm/transparent_hugepage/enabled
设置　echo “always” > /sys/kernel/mm/transparent_hugepage/enabled

3.2.2.2. vm.*
vm.dirty_background_ratio: 设置 dirty pages 开始后台回写时的百分比
vm.dirty_ratio: 设置 dirty pages 开始回写时的百分比
vm.swappiness: 控制从物理内存换出到交换空间的相对权重，取值为 0 到 100。更低的值导致避免交换，而更高的值导致尝试使用交换空间

3.2.3. XFS文件系统参数
3.2.3.1.    nobarrier
启用/禁用使用块层写barrier。 写入barrier确保某些IO通过设备高速缓存并在永久存储上。 如果在具有易失性（非电池支持的）回写式高速缓存的设备上禁用，nobarrier选项将导致系统崩溃或断电时的文件系统损坏。使用如下命令修改，有两种修改barrier模式的办法：
•在mount中指定：mount -o nobarrier /dev/sdb1 /mnt/mountpoint
•在/etc/fstab中指定：/dev/sdb1 /testfs xfs defaults,nobarrier 0 0

3.2.3.2. 选择文件系统的日志模式
大多数文件系统都支持如下三种和日志相关的参数，也就是mount中的data选项。我们建议对的默认文件系统参数做调整：
•data=jounal
这个日志选项通过记录数据和元数据，提供给最高的数据一致性。也带来最大的性能损耗。
•data=ordered （default）
在这个模式下，只会记录元数据。文件数据优先写入。这是默认的设置。
•data=writeback
该选项以数据一致性为代价，提供了最快的数据访问。注意，日志模式只影响写入性能。如果主要是读数据的负载（如web服务器），那么修改日志模式也没有用。

有两种修改日志模式的办法：
•在mount中指定:mount -o data=writeback /dev/sdb1 /mnt/mountpoint
•在/etc/fstab中指定：/dev/sdb1 /testfs xfs defaults,data=writeback 0 0

3.2.3.3. journal_dev
XFS日志的默认位置与数据在同一个块设备上。 因为同步元数据写入日志必须在任何关联数据写入启动之前成功完成，所以这种布局可能会导致数据库服务器上典型工作负载模式的磁盘争用。 为了克服这个问题，可以将日志放置在具有低延迟I/ O路径的独立物理设备上。 由于日志通常只需要很少的存储空间，因此这种安排可以显着提高文件系统的I / O吞吐量。 日志的合适主机设备是固态驱动器（SSD）设备或具有电池支持的回写式高速缓存的RAID设备。
要在创建XFS文件系统时保留具有指定大小的外部日志，请对mkfs.xfs命令指定-l logdev = device，size = size选项。 如果省略大小参数，则mkfs.xfs会根据文件系统的大小选择日志大小。 要mount XFS文件系统以使其使用外部日志，请为mount命令指定-o logdev = device选项。

3.2.4.    磁盘参数
3.2.4.1.    readahead
读取文件列表的内容到内存，以便当实际需要时可从缓存读取通过修改/sys/block/sda/queue/read_ahead_kb的值进行设置。

3.2.4.2. scheduler
I/O 调度器的设置包括如下几种：
cfq：Completely Fair Queueing（完全公平队列）调度器，它将进程分为实时、尽其所能和空闲三个独立的类别。实时类别的进程先于尽其所能类别的进程执行，而尽其所能类别的进程总是在空闲类别的进程之前执行。默认情况下分配到尽其所能类别的进程
deadline：尝试为 I/O 请求提供有保障的延迟。适用于大多数情况，尤其是读取操作比写入操作更频繁的请求
noop：执行简单的 FIFO（先进先出）调度算法，并实现请求合并。适合使用快速存储的 CPU 计算密集型系统

# 查看当前使用的 I/O 调度器
cat /sys/block/sda/queue/scheduler

# 将 I/O 调度器设为 deadline
echo “deadline” > /sys/block/sda/queue/scheduler

3.2.5. 内核调度
3.2.5.1.    kernel.sched_min_granularity_ns
针对 CPU 计算密集型任务设置调度器的最小抢占粒度

3.2.5.2.    kernel.sched_wakeup_granularity_ns
设置调度器的唤醒粒度，这将延迟抢占效应，并减少过度调度

3.2.5.3.    kernel.sched_migration_cost_ns
该变量用来判断一个进程是否还是hot，如果进程的运行时间（now – p->se.exec_start）小于它，那么内核认为它的code还在cache里，所以该进程还是hot，那么在迁移的时候就不会考虑它。

3.2.6.    网络参数
3.2.6.1.     net.ipv4.{tcp_rmem,tcp_wmem,udp_mem}
tcp_rmem：用于 autotuning 函数,设置 TCP 接收缓冲的最小、默认及最大字节数
tcp_wmen：用于 autotuning 函数,设置 TCP 发送缓冲的最小、默认及最大字节数
udp_mem：设置 UDP 队列的页数

3.2.6.2.     net.core.busy_{read,poll}
net.core.busy_read: 针对 socket 读取设置低延迟 busy poll 超时
net.core.busy_poll: 针对 poll 和 select 设置低延迟 busy poll 超时
net.ipv4.tcp_fastopen: TCP 快速打开（TFO）

3.2.7.    Tuned策略
tuned是一个守护进程，它使用udev监视连接的设备，并根据选定的配置文件静态和动态地调整系统设置。 tuned分布有许多预定义的配置文件，用于高吞吐量，低延迟或节能等常见使用情况。 可以修改为每个配置文件定义的规则，并自定义如何调整特定的设备。 要恢复某个配置文件对系统设置所做的所有更改，可以切换到其他配置文件或取消激活已调整的服务。
tuned包括许多用于典型用例的预定义配置文件，可以使用tuned-adm程序轻松激活这些配置文件。tuned会对CPU，内存，磁盘，内核调度，网络同时进行系统的优化。

3.2.7.1.    throughput-performance
为高吞吐量而优化的服务器配置文件，它禁用省电机制并启用sysctl设置，以提高磁盘，网络IO的吞吐量性能，并切换到deadline调度程序。 CPU调速器设置为性能。

3.2.7.2.    latency-performance
针对低延迟优化的服务器配置文件。 它禁用省电机制，并启用sysctl设置来改善延迟。 CPU调控器被设置为性能，并且CPU被锁定到低C状态（通过PM QoS）。

3.2.7.3.    network-latency
低网络延迟调整的配置文件。 它基于latency-performance配置文件。 它另外禁用透明的巨大页面，NUMA平衡和调整几个其他网络相关的sysctl参数。

3.2.7.4.    network-throughput
网络吞吐量调整配置文件。 它基于throughput-performance配置。 它另外增加了内核网络缓冲区。

4. Gluster调优测试效果
针对上述的优化配置选项，采用 “Hot Tier : Distributed-Replicate 3 x 2 = 6，Cold Tier: Distributed-Disperse  7 x (2 + 1)”卷分别对“64KB小文件6:4随机混合读写”和“4KB小文件100%顺序读”两个测试用例进行了测试。其中“64KB小文件6:4随机混合读写”这个测试用例主要用来评估系统小文件OPS性能，“4KB小文件100%顺序读”这个用例主要用来评估系统小文件延时性能。
4.1.    测试环境
4.1.1.    硬件配置

4.1.2.    软件配置
GlusterFS：XDFS 5.4.6 (Gluster 3.10.3)
操作系统：CentOS 7.2，采用CentOS-7-x86_64-Minimal-1511最小ISO安装

4.1.3.    测试工具
vdbench 504

4.2.    测试说明
Storage server上创建的卷通过nfs挂载在Client上进行测试

4.3.    测试结果
4.3.1.    64KB小文件6:4随机混合读写
Vol配置：
Hot Tier : Distributed-Replicate 3 x 2 = 6
Cold Tier: Distributed-Disperse  7 x (2 + 1)
Vdbench用例:
fsd=fsd1,anchor=/mnt/xdfs/235,depth=2,width=10,files=2000,size=64k,shared=yes
fwd=format,threads=24,xfersize=32k
fwd=default,openflags=directio,xfersize=32k,fileio=random,fileselect=random,rdpct=60,threads=24
测试结果:

根据以上单项参数调优的测试结果，选出对OPS有提升作用的参数（测试结果标记为黄色的参数），全部设置这些参数后的测试结果如下（vm.dirty_ratio，vm.dirty_background_ratio，vm.swappiness，kernel.sched_min_granularity_ns，kernel. sched_wakeup_granularity_ns会在tuned-adm中设置，无需重复设置）。可以看到优化后OPS可提升40.0%,延时可下降21.0%。

4.3.2. 4KB小文件100%顺序读
Vol配置：
Hot Tier : Distributed-Replicate 3 x 2 = 6
Cold Tier: Distributed-Disperse  7 x (2 + 1)
Vdbench用例:
fsd=fsd1,anchor=/mnt/xdfs/235,depth=2,width=10,files=2000,size=4k,shared=yes
fwd=format,threads=24,xfersize=4k
fwd=default,openflags=directio,operation=read,xfersize=4k,fileio=random,fileselect=sequential,threads=24
测试结果:

根据以上单项参数调优的测试结果，选出对延时和OPS有提升作用的参数（测试结果标记为黄色的参数），全部设置这些参数后的测试结果如下（vm.dirty_ratio，vm.dirty_background_ratio，vm.swappiness，kernel.sched_min_granularity_ns，kernel.sched_migration_cost_ns，net.core.busy_read, net.core.busy_poll, net.ipv4.tcp_fastopen会在tuned-adm中设置，无需重复设置）。可以看到优化后OPS可提升185.0%，延时可下降34.2%。

4.3.3. Linux查找命令测试
Vol配置：
Hot Tier : Distributed-Replicate 3 x 2 = 6
Cold Tier: Distributed-Disperse  7 x (2 + 1)
测试用例:
mnt/xdfs/235,depth=2,width=10,files=2000,size=4k,shared=yes
fwd=format,threads=24,xfersize=4k
测试结果:

可以看到由于测试用例中小文件都存放在热卷（1+1副本卷）中，优化效果不是很明显，对于ls -lR|wc –l操作，performance.nfs.stat-prefetch on有一定的优化效果，对于find –name和find –size操作，performance.parallel-readdir on有较好的优化效果。
Vol配置：
Distributed-Disperse  8 + 1
测试用例:
mnt/xdfs/235,depth=2,width=10,files=2000,size=4k,shared=yes
fwd=format,threads=24,xfersize=4k
测试结果:

可见对于EC纠删码卷，优化效果不是很明显，对于ls -lR|wc –l操作，performance.nfs.stat-prefetch有一定的优化效果，对于find –name操作，三个优化选项都有一定的优化效果。

4.4. 调优结论
通过对以上测试结果可以看出，在对Gluster和OS进行优化之后“64KB小文件6:4随机混合读写”OPS可提升28.7%,延时可下降15.6%，“4KB小文件100%顺序读”OPS可提升185.0%，延时可下降34.2%。实验证明，通过系统的优化Gluster和OS的配置，可以有效的改善海量小文件场景下的OPS和延时性能，同时测试结果也说明了系统调优对查找类操作的优化效果有限。建议在实际系统中如果遇到海量小文件的使用场景，使用本次测试最后使用的优化选项对系统OPS和时延进行优化。建议配置如下：

具体配置请根据硬件环境做出进一步的调整，例如如果系统CPU核心数较多，可将client.event-threads、server.event-threads和performance.io-thread-count调高一些，如果系统内存较大，可将nfs.mem-factor调高一些，以取得更好的性能调优结果。

由于Gluster在设计上并没有针对小文件的提供特别的优化，使用系统参数调优的效果终究有限，如果希望进一步提升小文件性能，还是需要从软件代码层面入手，对Gluster进行优化，可以考虑的优化方向包括：

• 合并小文件，小文件合并存储是目前优化LOSF问题最为成功的策略，已经被包括Facebook Haystack和淘宝TFS在内多个分布式存储系统采用。它通过多个逻辑文件共享同一个物理文件，将多个小文件合并存储到一个大文件中，实现高效的小文件存储。这种机制对于WORM(Write Once Read Many)模式的分布式存储系统非常适合，可以显著提升系统的读性能。
• 增加元数据服务，在服务端增加内存级的持久元数据，可以有效提高小文件读写IOPS、多级目录下的文件访问加速、海量目录项读取加速。可以显著增加系统ls等操作的性能。
• 针对小文件增加cache，可以显著增加系统的读性能。
• 针对Gluster通信进行优化，减少网络交互次数，可以提升系统OPS，减少延时。参考文献
  1.    Red_Hat_Gluster_Storage-3.3-Administration_Guide-en-US
  2.    Dan Lambright. Challenges_Persistent_Memory_Distributed_Storage_Systems
  3.    张晓. 云存储系统评测与优化
  4.    Dustin Black, Ben Turner. rh-summit-2017-dblack-bturner-gluster-architecture-and-performance-20170502-final-with-101
  5.    D.John Shakshober, Larry Woodman, Bill Gray, Joe Mario. Performance Analysis and Tuning
  6.    Poornima Gurusiddaiah, Raghavendra Gowdappa, Manoj Pillai. Improving Performance of Directory Operations in Gluster
  7.    GlusterFS 3.0.0 Release Notes
  8.    Eduardo Ciliendo, Takechika Kunimasa, Byron Braswell.  Linux性能调优指南
  9.    刘爱贵. 海量小文件问题综述
  10.    李柱. 分布式文件系统小文件性能优化技术研究与实现
  11.    何华. GlusterFS的数据分布策略与性能优化研究
  12.    海量“小文件”优化秘籍：GlusterFS
  13.    gluster性能调优选项（中继器）详解