Re: doubt about 99% of the cases if the first byte of the file is cached.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Unless there is a tux-devel list, I'd say it belongs here. If there is a tux-devel list, I'd say it belongs on it.

Alex Kramarov wrote:
I have been following this conversation for a long, long time, and though
this is tux related, it doesn't seem that it belongs in this list. does
anybody else feel the same ? maybe this should be private between the core
tux developers and Liang ?

-------Original Message-------

From: tux-list@redhat.com
Date: Tuesday, April 23, 2002 19:04:20
To: mingo@elte.hu
Cc: tux-list@redhat.com
Subject: RE: doubt about 99% of the cases if the first byte of the file is
cached.

Hi, Ingo

In our test case, we just build 10 files and each file is 5MB,10 files and
each file is 10MB, 10 files and each file is 50MB. The main memory of
TUX server is 256MB.

Why we build such big files for testing, the reason is we want linux to
flush out those files when the cache limit is reached. So we can update
caching status table in proxy.

We already test the feasibility of our project when we will use
flush_inode_pages()
in our program to flush a speicifc file. But now we want to get a real
flush
by Linux itself.

Now the question is can we know the maximum cache size of a backend
server running Linux 2.4.18 if the main memory is 256MB?

BTW, we record the time for the request of a speicifc file in our test case.
We found if the total size of all those http request files is bigger than
100MB, then the
request time for a file again and again will be increased instead of
decreased.
So the performance of TUX is not improved because Linux take much time to
swap between cache and disk.

But if the total size of all those http request files is less than 100MB,
then the
request time for a file again and again will be decreased. So the
performance
of TUX is improved because Linux already cached all these files in cache.

Is this result reasonable?

Liang



-----Original Message-----
From: mingo@e2.elte.hu [mailto:mingo@e2.elte.hu]On Behalf Of Ingo Molnar
Sent: Tuesday, April 23, 2002 7:43 AM
To: Liang Yang
Cc: tux-list@redhat.com
Subject: RE: doubt about 99% of the cases if the first byte of the file is
cached.



On Tue, 23 Apr 2002, Liang Yang wrote:


But even we didn't enable noatime, LED should flash only for 1/10 second
or shorter time since Linux just need to update the access time flag of
this file. it is not a big job and it shouldn't take Linux a long time
to update this filed. But we noticed the Hard Disk LED flash for almost
2 seconds each time. So maybe Linux is doing some large amount hard disk
read/write operation instead of just updating file access time flag.


well, is RAM large enough for all files accessed to be cached in RAM?


I guess for all the sizes of files, the access time flag should be the
same. Is that correct?


yes, but each file has a different access flag, in different on-disk
positions. So if you are accessing 100 files, the atime update sequence
might create a longer LED flashing.

Ingo

--
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support





[Index of Archives]     [Apache Users]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Packaging]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Docs]