From: "Henrik Nordstrom" <henrik@henriknordstrom.net>
>> avg-cpu: %user %nice %system %iowait %steal %idle
>> 0.92 0.00 1.09 6.16 0.00
91.83
>
>
> It's not much blocking on disk I/O either, only 6.16%. 91.83% of the
> time your server is doing absolutely nothing.
The said computer has two 4-core CPU, which is registered as 8 processors
to the Linux. Perhaps that's why the CPU utilization is registered as low.
> > And it seems the io wait figures is building
>> up. I am worried that it will continue to build up and causing bottle
>> necking.
>
>There is a significant increase in disk I/O transactions when the cache
>has been filled and Squid starts to recycle space. Then it levels out
>and stays relative to the amount of cachable traffic you have.
You are obsolutely right about that observation, unfortunately I did not
know how to deal with this transition and users are complaining slow
http response and I had to put Squid off-line. From being able to
handle 9000 requests concurrently, I don't know for want changes I made
( or for what reasons ), it reduced to 1300 requests and I had to
finally retire Squid. Whereas somehow the other commercial unit is
able to somehow hand 15000 server request concurrently. Sad that I
could not make it to using squid.
Another problem I see is that a typical service provider cache engine
will get considerable amount of DoS/syn-flood attacks ( at port 80 ).
Netfilter connection tracking becomes double edge sword. Perhaps I
did not plan out a good scheme to deal with that from the start.
Best regards.
Received on Tue Aug 14 2007 - 19:56:31 MDT
This archive was generated by hypermail pre-2.1.9 : Sat Sep 01 2007 - 12:00:03 MDT