'Tomasz Papszun wrote:'
> On Tue, 28 Apr 1998, Dirk Vleugels wrote:
>
> > Solaris will do _all_ the disk IO via pagein/pageout. So these number
> > is by no means a sign that your squid binary get paged to disk very
> > frequently.
>
> Hello,
> thanks to all who replied my question which sounded:
> "Can anybody confirm such ratio is normal for Solaris?".
>
>
> Provided there's no any obvious misconfiguration at my box, this must be
> the way Solaris is.
Yep.
Just FYI, our parent runs on a dedicated SPARCstation 20 with Solaris 2.5.1
384 MB RAM (squid never uses more than 245 MB RSS/340 MB VSZ)
and 10 GB UWD-SCSI effective cache area.
cache_mem 192
cache_swap_low 94
cache_swap_high 96
cache_swap 12000
maximum_object_size 12228
info:
Squid Object Cache: Version 1.1.16
Start Time: Wed, 08 Apr 1998 18:04:08 GMT
Current Time: Tue, 28 Apr 1998 16:06:52 GMT
Connection information for squid:
Number of TCP connections: 2592717
Number of UDP connections: 5872566
Connections per hour: 17708.1
Select loop called: 53216967 times, 32.339 ms avg
Cache information for squid:
Storage Swap size: 9443 MB
Storage Mem size: 149855 KB
Storage LRU Expiration Age: 6.63 days
Requests given to unlinkd: 266683
Unused fileno stack count: 0
Resource usage for squid:
CPU Time: 137328 seconds (64687 user 72641 sys)
CPU Usage: 8%
Maximum Resident Size: 0 KB
Page faults with physical i/o: 3490731
TOTAL: 35317966 KB transferred
Except the low LRU EA (need more hdds or reduce maximum_object_size a little
bit ;-)) this looks ok for me. I already tried it with cache_mem 120 but
there was no big change related to Page faults with physical i/o (when
I set it higher than 210, than pfs grow up ;-)) ...
(i.e. 0.41 pf/conn or 0.59 pf/tcpc if you want to take this for comparision).
Have fun,
Jens.
-- +---[ Jens Elkner ]------[ IVS, Otto-von-Guericke-Universitaet Magdeburg ]-+ | Am Uniplatz 5 | | WH 4 PF 310 elkner@ivs.cs.uni-magdeburg.de | | 39106 Magdeburg GERMANY http://ivs.cs.uni-magdeburg.de/~elkner | +--------------------------------------------------------------------------+Received on Tue Apr 28 1998 - 10:07:22 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:39:58 MST