From: "Henrik Nordstrom" <henrik@xxxxxxxxxxxxxxxxxxx> >> 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.
