Re: comparison of the NOVM version

> From: Oskar Pearson <oskar@is.co.za>
> Andres Kroonmaa wrote:
> >
> > Guess: NOVM is slightly faster on HIT's because there is no delay of
> > objects being swapped in into VM initially.
> >
> > Then again, if pushed by zillions of small MISS requests I think NOVM
> > would be slower somewhat as each fileopen adds additional time to
> > request service times.
>
> Just a simple test:
>
> > time ./open-test
> 0.020u 0.890s 0:01.66 54.8% 0+0k 0+0io 66pf+0w
> > cat open-test.c
>
> for (a=0;a <10000;a++){
> b = open("temp.a","rw+");
> close(b);
> }
>
> 10000 open and closes of a file takes just over 1.5 seconds (and yes, gcc
> hasn't optimised the system calls out of existance, as an strace shows
> the calls.
>
> I really don't think that this is a limiting factor... of course reading
> 10000 places in ram is a lot faster... but the time difference is
> really worth ignoring.
>
> I know that opening and closing files in random places on the disk is a
> better idea, but it'll take to long to write the code ;)

    You forget, that busy and big caches has 500K and far more objects
 on disk, thousands of directories, and its writing algoritm goes through
 all of them before reusing same directory again. that means that to have
 all the directories in cache would need quite a bunch of DNLC cache
 which wastes memory (few MB-s), the other var is inode cache which gets
 flooded by squid anyway and always, and to have it big enough would
 mean tens of MB-s of ram as each inode takes 512 bytes. Open files
 still use inodes and these are locked in ram, so a tuned cache with
 big inode cache and lots of open files will have tens of MB-s dead
 reducing free ram for squid even more.

    Your test sample didn't ever go to disk io, except the very first
 time and some time later after the last one to flush updated inode.

    In real life, file open means directory search, inode search, read,
 inode update (for accesstime), possibly a flush of some other buffers,
 all with pretty much seek activity of disks. All this adds up to
 several mSecs per open.

-------------------------------------------------------------------
 Andres Kroonmaa Telefon: 6308 909
 Network administrator
 E-mail: andre@ml.ee Phone: (+372) 6308 909
 Organization: MicroLink Online
 EE0001, Estonia, Tallinn, Sakala 19 Fax: (+372) 6308 901
-------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:41 MDT