On Sat, 22 May 1999, Henrik Nordstrom wrote:
> Jorg B. wrote:
>
> > I reviewed my "General Runtime Information" and noticed the
> > following: Page faults with physical i/o: 104168
> > By reading the faq it seems to have a problem with memory resources...
>
> It MAY be an indication of memory shortage. This is not a definite rule
> and is affected by a lot of factors, and depends a lot on which OS you
> are running on. On Solaris for example this value is mostly useless as
> all it indicates is that there has been I/O which involved physical disk
> I/O.
Ok, just for the heck of it I put 256MB more Ram into this box which brought it
up to 512MB of RAM. However, the number of "Page faults with physical i/o:" did
not improve. :-(
> > Could somebody take a look at the stats below and give me some hints
> > on what my problem may is.
>
> Are you sure you have a problem?
Well, sometimes the cache server just seems to take a while before it will
process the request... (a second or two) I thought that this mat be related to
the Page faults.
>
> > Processors: 2 Pentiums 350's
> [defenitely overkill from what it looks below]
I wanted to have some extra cpu power ;-)
> > Memory: 256 MB's
> [more than plenty at this time it seems. see below.]
I'm now up to 512MB...
> > Select loop called: 8717162 times, 14.426 ms avg
> [looks fine]
>
> > Median Service Times (seconds) 5 min 60 min:
> > HTTP Requests (All): 0.16775 0.17711
> > Cache Misses: 0.35832 0.27332
> > Cache Hits: 0.03066 0.02742
> > Near Hits: 0.24524 0.20843
> > Not-Modified Replies: 0.00919 0.02190
> > DNS Lookups: 0.00000 0.00000
> > ICP Queries: 0.00000 0.00000
> [looks very fine]
>
> > Resource usage for squid:
> > UP Time: 125749.689 seconds
> > CPU Time: 5049.620 seconds
> > CPU Usage: 4.02%
> > CPU Usage, 5 minute avg: 2.64%
> > CPU Usage, 60 minute avg: 3.36%
> [looks very fine]
>
> > Maximum Resident Size: 0 KB
> > Page faults with physical i/o: 104168
> [probably irrelevant]
>
> > Memory usage for squid via mallinfo():
> > Total space in arena: 33569 KB
> [256 - 33 leaves a lot of memory for OS and FS cache... very fine]
>
> > Ordinary blocks: 33021 KB 21265 blks
> > Small blocks: 0 KB 0 blks
> > Holding blocks: 344 KB 2 blks
> > Free Small blocks: 0 KB
> > Free Ordinary blocks: 548 KB
> > Total in use: 33365 KB 99%
> > Total free: 548 KB 2%
> > Memory accounted for:
> > Total accounted: 25962 KB
> [total in use - total accounted is not to great. this is also fine]
This should have improved since I put more RAM into this box.
> > File descriptor usage for squid:
> > Maximum number of file descriptors: 256
> [this may become a problem.. I would rather see 1024 there]
Ok, here it becomes a little bit tricky...
Even though I've been using Linux for about 4 years now, I have never had a
reason to increase the number of filedescriptors... therefore I'm a little bit
rusty when it comes to that. I also thought that linux kernel 2.2.x already has
a higher filedescriptor set by default.
Anyway,
I know I have to do a `echo xxx > /proc/sys/fs/file-max` and a
`echo xxx > /proc/sys/fs/inode-max`
(where "xxx" is going to be the new value)
I read that I should also modify the OPEN_MAX
value within the /usr/include/linux/linits.h file.
The current values are:
file-max: 4096
inode-max: 16376
OPEN_MAX: 256
Should I just take the above values times 4 (ie. 4096*4 = 16384) ?
Also, I don't really understand the cache_mem option within the squid.conf
file... I searched around the archives and read the faq 3 times but I still
don't understand if you need a large cache_mem ? So, in my case with 512MB of
RAM on a box that does ONLY squid what should my cache_mem be ?
Thank you very much for your help....
Thanks
Jorg B.
Received on Mon May 24 1999 - 08:27:16 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:46:24 MST