copying pkgsrc tree around jails on beefy machine - fast on 2nd iteration, a bit slower than first on 3rd iteration

[Hiten Pandya]

Miguel Filipe wrote:
On 1/2/06, Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:

:Hello!
:
:       While testing 1.4rc with jails - actually preparing for jails I noticed this:
:
:dk# cd /usr/
:dk# time cp -pr pkgsrc /jails/pgsql81/usr
:0.296u 9.586s 2:09.93 7.5%      59+440k 26099+1175io 90342pf+0w
:dk# time cp -pr pkgsrc /net/jails/oglasi/usr
:0.429u 8.692s 0:48.14 18.9%     61+447k 1816+1175io 7084pf+0w
:dk# time cp -pr pkgsrc /jails/mysql/usr
:0.445u 14.146s 2:12.14 11.0%    56+415k 1889+1176io 80390pf+0w
:dk# du -sk /usr/pkgsrc
:357080  /usr/pkgsrc
:
:
:Basically I was copying 357MB pkgsrc dir from master to jails in a row. I manually re-edited destination each time. All
:in a row, but you can see that 3rd copy did not benefit at all from first two copies. Since this machine is waiting for
:those jails to actually do something I was under impression that 4GB RAM that this machine sees will benefit a lot in
:copying - something like in 2nd case, but I was surprised that caching did not help at all in third case even though
:things were being copied in a row - usually few seconds apart. Isn't DFly one of so called lazy-swappers where things do
:not go out of memory if memory needs for programs are low?
:
:Toma¾
   This is likely just the vnode cache getting blown out.  /usr/pkgsrc has
   over 100,000 files and directories in it.


 Hi,

 I'm not shure I got that right, in a machine with 4GB of ram, FS
caching of  ~380MB  of small files,  exausts the vnode cache?
 Is this okay? shouldn't it be able to cache it?
I think it would be advisable to tune some of the VM and Buffer cache
parameters so they take full advantage of 4G of RAM.  Believe it or not,
it is not exactly auto-tuning.  I am sure the dirent cache can be tuned
as well.
Kind regards,

Hiten Pandya