<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 3, 2022 at 5:41 PM Robin Lee Powell via rsync <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Wed, Aug 03, 2022 at 02:04:22PM -0400, Rob Campbell via rsync wrote:<br>
> The problem isn't that there are many syncs because the problem happens on<br>
> the first one that runs.<br>
<br>
You didn't actually say what the problem *is*.<br>
<br>
I can infer from the subject that you think it's bad that rsync is<br>
using a bunch of disk/buffer cache, but that's not rsync, that's<br>
Linux, and it's by design; Linux uses as much RAM as it possibly can<br>
for disk cache, always.  This improves performance.  In a<br>
well-performing Linux system, the "free" column of "free -h" is very<br>
low, and the "available" column is very high.<br></blockquote><div><br></div><div>Linux does indeed try to put your RAM to good use, and often that means caching data from disk in RAM.</div><div><br></div><div>However, if you transfer a large amount of data and do not intend to retransmit that data any time soon, then the memory isn't really put to good use, and can actually cause your system to slow down significantly - particularly if there's a lot of such data transferred.</div><div><br></div><div>It is, however, theoretically possible to skip the buffer cache using O_DIRECT, but that requires your application to have O_DIRECT support, or to use something like <a href="https://stromberg.dnsalias.org/~strombrg/libodirect/">https://stromberg.dnsalias.org/~strombrg/libodirect/</a></div><div><br></div><div>HTH.<br></div></div></div>