Re: 1.1.22 -> 2.X migration path && Solaris performance

From: T. Esting <t_esting@dont-contact.us>
Date: Wed, 14 Apr 1999 08:46:09 PDT

On Wed, 14 Apr 1999 17:22:07 +0200, Michael Beckmann wrote:

> If your system couldn't handle the load initially due to disk wait,
> it is quite normal that, when the disk bottleneck is removed, your
> system handles more load, hence you get more CPU utilization.
>
[...]
> Your server really seems highly loaded. May I suggest that you add more
> dnsservers.
>
> You should say a little bit more about the disk configuration, your
> directory structure, and with which compiler and options you compiled
> Squid.
>
>
> Michael

  Michael -

  Thanks for the reply. The system is an Ultra5 with a 270MHz UltraSparc
IIi, 256MB RAM and two disks (separate controllers). The logs go onto the
internal drive and the cache is on a separate controller. I compiled squid
(both releases) with gcc 2.8.1 and async_io turned on for 2.1PATCH2.
Regarding the shifting of the bottleneck, I agree wholeheartedly. I guess I
just didn't expect it to shift towards run queue - I figured it would shift
towards user/system time or possibly memory. Here is a typical day with
squid 1.1.22:

bash$ sar -qu -f /var/adm/sa/sa05 -s 09:00 -e 11:00

SunOS proxyB 5.6 Generic_105181-03 sun4u 04/05/99

09:00:03 runq-sz %runocc swpq-sz %swpocc
09:20:04 1.2 2
09:40:06 1.3 2
10:00:06 1.2 2
10:20:04 1.1 3
10:40:04 1.4 2

Average 1.2 2

09:00:03 %usr %sys %wio %idle
09:20:04 20 14 65 1
09:40:06 22 14 64 0
10:00:06 22 15 63 0
10:20:04 23 14 63 0
10:40:04 22 14 63 0

Average 22 14 64 0

Here are the same numbers with 2.1PATCH2:

bash$ sar -qu -f /var/adm/sa/sa05 -s 09:00 -e 11:00

SunOS proxyB 5.6 Generic_105181-03 sun4u 04/12/99

09:00:00 runq-sz %runocc swpq-sz %swpocc
09:20:01 3.6 17
09:40:00 4.2 33
10:00:01 5.4 49
10:20:00 5.3 49
10:40:01 5.3 44
11:00:00 5.4 52

Average 5.1 41

09:00:00 %usr %sys %wio %idle
09:20:01 12 15 15 57
09:40:00 20 27 19 35
10:00:01 27 37 16 20
10:20:00 31 35 16 18
10:40:01 29 33 17 21
11:00:00 34 37 11 18

Average 26 31 16 28

I kept the total number of dnsservers and redirectors relatively stable
between releases, so I would not have expected a run queue issue to occur:
we did not introduce more processes fighting for the CPU or even that much
more -work- happening on the part of the users.

   Thanks again for your help.

   Erick.

>
>
> On Wed, Apr 14, 1999 at 05:02:56AM -0700, T. Esting wrote:
> > This was accidentally posted last night without a subject - I
apologize.
> >=20
> >=20
> > Dear Squid community -
> >=20
> > On an Ultra5/267MHz/256MB machine, we have been able to wheeze by
> > serving several thousand users (20-40K requests / hr) using squid
1.1.2=
> 2.
> > However, we spend the majority of our time in disk wait mode. I
recent=
> ly
> > upgraded to 2.1PATCH2 and asynchronous I/O seemed to take care of that
> > bottleneck rather nicely. However, while the change improved I/O, it
s=
> eemed
> > to
> > dramatically affect CPU usage: our run queue sizes went from=20
> > 1 < q < 2 to 2 < q < 10=20
> > (tragic for a single-CPU machine). %runocc suffered similarly, and the
> > system overall became less usable than the version 1 system. Have
othe=
> rs
> > experienced the same issue? Are there workarounds in later versions of
> > squid 2.x? Are there tuning parameters (4 dnsservers were kept
constan=
> tly
> > busy by our user load, as well as 8 redirectors) that ought to be
consi=
> dered
> > and/or reconsidered?
> >=20
> > Thanks.
> >=20
> > Erick.
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > _______________________________________________________
> > Get your free, private email at http://mail.excite.com/
> >=20
>
> --=20
> Michael Beckmann Backbone Manager
> Talkline GmbH, GB Internet
> S=FCderstra=DFe 73 Telefon: +49 40 237836-13=20
> 20097 Hamburg, Germany Fax: +49 40 237836-64

_______________________________________________________
Get your free, private email at http://mail.excite.com/
Received on Wed Apr 14 1999 - 09:52:41 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:45:51 MST