<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 10:42 AM, Jonathan Lu <span dir="ltr"><<a href="mailto:jojokururu@gmail.com" target="_blank">jojokururu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013/6/17 18:59, Robert van Leeuwen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm facing the issue about the performance degradation, and once I glanced that changing the value in /proc/sys<br>
/vm/vfs_cache_pressure will do a favour.<br>
Can anyone explain to me whether and why it is useful?<br>
</blockquote>
Hi,<br>
<br>
When this is set to a lower value the kernel will try to keep the inode/dentry cache longer in memory.<br>
Since the swift replicator is scanning the filesystem continuously it will eat up a lot of iops if those are not in memory.<br>
<br>
To see if a lot of cache misses are happening, for xfs, you can look at xs_dir_lookup and xs_ig_missed.<br>
( look at <a href="http://xfs.org/index.php/Runtime_Stats" target="_blank">http://xfs.org/index.php/<u></u>Runtime_Stats</a> )<br>
<br>
We greatly benefited from setting this to a low value but we have quite a lot of files on a node ( 30 million)<br>
Note that setting this to zero will result in the OOM killer killing the machine sooner or later.<br>
(especially if files are moved around due to a cluster change ;)<br>
<br>
Cheers,<br>
Robert van Leeuwen<br>
</blockquote>
<br></div>
Hi,<br>
    We set this to a low value(20) and the performance is better than before. It seems quite useful.<br>
<br>
    According to your description, this issue is related with the object quantity in the storage. We delete all the objects in the storage but it doesn't help anything. The only method to recover is to format and re-mount the storage node. We try to install swift on different environment but this degradation problem seems to be an inevitable one.<br>
</blockquote><div>It's inode cache for each file(object) helps (reduce extra disk IOs).  As long as your memory is big enough to hold inode information of those frequently accessed objects, you are good.  And there's no need (no point) to limit # of objects for each storage node IMO.  You may manually load inode information of objects into VFS cache if you like (by simply 'ls' files), to _restore_ performance.  But still memory size and object access pattern are the key to this kind of performance tuning, if memory is too small, inode cache will be invalided sooner or later.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Jonathan Lu<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/<u></u>ListHelp</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Regards<br>Huang Zhiteng
</div></div>