Dear Adrian, Well my conclusion that this is an IO problem came from the fact that I see huge IO waits as the volume of traffic increase (with tools such as mpstat), when using ramdisk there is no such issue. I have configured the SSD drive with ext2, no journal, noatime. Used the “noop” I/O scheduler. In /etc/fstab /dev/sdb1 /cache ext2 defaults,noatime 1 2 hdparm results: hdparm -t /dev/sdb1 /dev/sdb1: Timing buffered disk reads: 304 MB in 3.01 seconds = 100.93 MB/sec ---- hdparm -T /dev/sdb1 /dev/sdb1: Timing cached reads: 4192 MB in 2.00 seconds = 2096.58 MB/sec Any ideas? Regards. Adrian Chadd-3 wrote: > > 2009/8/2 smaugadi <adi@xxxxxxxxxxxx>: >> >> Dear Adrian, >> During the implementation we encountered issues with all kind of >> variables >> such as: >> Limit of file descriptors (now the squid is using 204800). >> TCP port range was low (increased to 1024 65535) TCP timers (changed >> them) >> The ip_conntrack and hash size were low (now 524288 262144 respectively) >> >> Now we are at a point that IO is the only issue. > > What profiling have you done to support that? For example, one of the > issues I had which looked like IO performance was actually because the > controller was completely unhappy. Upgrading the firmware on the > controller card signficantly increased performance. > > But I think you need to post some further information about the > problem. "IO" can be rooted in a lot of issues. :) > > > Adrian > > -- View this message in context: http://www.nabble.com/Squid-high-bandwidth-IO-issue-%28ramdisk-SSD%29-tp24775448p24776193.html Sent from the Squid - Users mailing list archive at Nabble.com.
