2.9.2. 使用 GFS2 调节性能

通常可以更改出问题的程序保存其数据的方法，这样可获得可观的性能优势。

典型的问题程序例子有电子邮件服务器。通常会制定包含每个用户的文件的 spool 目录（mbox），或者为每个用户创建一个目录，其中有包含所有信息的文件（maildir）。当有来自 IMAP 的请求时，理想的情况是为每个用户赋予一个对特定节点的亲和性。那么将会使用那个节点中的缓存处理他们查看和删除电子邮件信息的请求。显然，如果那个节点失败，那么可在不同的节点中重启该会话。

When mail arrives via SMTP, then again the individual nodes can be set up so as to pass a certain user's mail to a particular node by default. If the default node is not up, then the message can be saved directly into the user's mail spool by the receiving node. Again this design is intended to keep particular sets of files cached on just one node in the normal case, but to allow direct access in the case of node failure.

This setup allows the best use of GFS2's page cache and also makes failures transparent to the application, whether imap or smtp.

备份通常是另一个令人纠结的问题。如果可能，最好直接从节点备份每个节点的工作集合，这样可缓存具体的内节点组。如果您可以定期运行的备份脚本，且与在 GFS2 中运行的应用程序反应时间完全一致，那么很有可能集群无法最有效地使用页面缓存。

Obviously, if you are in the (enviable) position of being able to stop the application in order to perform a backup, then this won't be a problem. On the other hand, if a backup is run from just one node, then after it has completed a large portion of the file system will be cached on that node, with a performance penalty for subsequent accesses from other nodes. This can be mitigated to a certain extent by dropping the VFS page cache on the backup node after the backup has completed with following command:

echo -n 3 >/proc/sys/vm/drop_caches

但这并不是一个好的解决方案，最好的方案是保证在每个节点中的工作集合要么是共享的（大多数为集群内只读），要么是从单一节点的大量访问。