DragonFly users List (threaded) for 2006-01
copying pkgsrc tree around jails on beefy machine - fast on 2nd iteration, a bit slower than first on 3rd iteration
On 1/2/06, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
> : 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?
> This is likely just the vnode cache getting blown out. /usr/pkgsrc has
> over 100,000 files and directories in it.
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?
Miguel Sousa Filipe