Re: Follow up on Benchmarking results for 3.1.10 vs 2.7.9

Hi, I have some more info on the 3.1.10 line I had to remove it from service and
roll back to 2.7.9 because of performance issue.

I noticed that during some peak usage CPU would spike to 100% then come down to
the high 70s but this caused numerous issues and errors. I reset the 3.1.10
instance on Dec 06, 2011 and let it run until it hit this threshold again and it
took about a day I have 3.1.10 running in a data center with have the load and
it is doing ok. I do see a high number of page faults for the short period of
time. I have the 3.1.10 instance still in place with all the logs and well
review things to see if I can determine the issue. I think I might try using a
small cache-dir and adjusting some mem settings.

I am also including some config info and if someone has ideas or suggestions
pleas let me know.

Resource usage for squid:
        UP Time: 45842.506 seconds
        CPU Time: 35590.969 seconds
        CPU Usage: 77.64%
        CPU Usage, 5 minute avg: 99.01%
        CPU Usage, 60 minute avg: 100.16%
        Process Data Segment Size via sbrk(): 1929256 KB
        Maximum Resident Size: 0 KB
        Page faults with physical i/o: 6

Squid Config info:

Squid Cache: Version 3.1.10-20101227
configure options: '--prefix=/usr/local/squid-3.1.10-20101227'
'--disable-maintainer-mode' '--disable-dependency-tracking'
'--enable-async-io=60' '--enable-storeio=ufs,aufs' '--enable-cache-digests'
'--enable-epoll' '--with-pthreads' '--enable-snmp' '--with-large-files'
'--enable-large-cache-files' '--enable-follow-x-forwarded-for'
'--with-maxfd=16384' '--disable-ident-lookups' '--disable-wccp'
'--enable-wccpv2' '--enable-removal-policies=heap,lru' '--enable-htcp'
'--enable-auto-locale' --with-squid=/usr/local/src/squid-3.1.10-20101227
--enable-ltdl-convenience
[root_at_cach1 local]# cat squid/etc/squid.conf
#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged)
machines

acl SSL_ports port 443
acl Safe_ports port 80 81 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl PURGE method PURGE

follow_x_forwarded_for allow localhost

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access allow manager localnet
http_access deny manager
http_access allow PURGE localhost
http_access deny PURGE

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

icp_access allow localnet

icp_access deny all
icp_port 3130

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

# Uncomment and adjust the following to add a disk cache directory.

cache_dir aufs /usr/local/squid/var/cache 75000 64 512

# Leave coredumps in the first cache dir
coredump_dir /usr/local/squid/var/cache

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

access_log none
cache_store_log none
cache_swap_low 98
cache_swap_high 99
cache_mem 512 MB
cache_peer xxxx sibling 3128 3130 proxy-only
cache_peer xxxx sibling 3128 3130 proxy-only
prefer_direct off
digest_generation on
digest_rebuild_period 10 minutes
digest_rewrite_period 10 minutes

memory_replacement_policy heap GDSF
cache_replacement_policy heap LFUDA
maximum_object_size 32 MB
maximum_object_size_in_memory 2 MB
request_header_max_size 64 KB
reply_header_max_size 64 KB
shutdown_lifetime 10 seconds
request_timeout 1 minutes
forward_timeout 2 minutes
positive_dns_ttl 300 seconds
negative_dns_ttl 29 seconds
negative_ttl 0 seconds
ipcache_size 40480
ipcache_low 97
ipcache_high 99
fqdncache_size 512
cache_mgr
visible_hostname walter
unique_hostname walter
logfile_rotate 10
forwarded_for off
pipeline_prefetch on
logfile_rotate 20
httpd_suppress_version_string on

Jack

----- Original Message ----
From: Jack Quinlin <jquinlin_at_yahoo.com>
To: squid-dev_at_squid-cache.org
Sent: Thu, January 6, 2011 10:44:21 AM
Subject: Follow up on Benchmarking results for 3.1.10 vs 2.7.9

Hi,

I have some benchmarking numbers that I would like to share with the community.
These numbers are from 2 servers that have the exact same hardware configuration

in the same data center receiving the same type of requests (not the best setup
for a SQUID server but that is a different story).

The server spec is below follwed by the benchmark numbers. I am looking to
improving the 3.1.10 config or adjust RHEL4 in efforts to reduce the CPU
consumption and improve hits. I will follow up with any improvements or findings

that find interesting.

Server Spec:

CPU: Dual Intel(R) Xeon(R) CPU L5310 @ 1.60GHz Quad Core
Mem: 4GB
HD: 450 SATA
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4) 32-bit, OS has been

tuned for 32-bit & RHEL 4.4

Squid Object Cache: Version 3.1.10-20101227
Users: 57
RPS: 1409
Hit Ratio Request: 36.3%, 36.4% , Byte: 47.6%, 48.6%
CPU Usage: 51.63%

Squid Object Cache: Version 2.7.STABLE9-20100923
Users: 55
RPS: 1419
Hit Ratio Request: 44.6%, 44.9% , Byte: 47.7%, 48.5%
CPU Usage: 33.42%

All comments and questions welcomed.

Thanks,

Jack

----- Original Message ----
From: Jack Quinlin <jquinlin_at_yahoo.com>
To: squid-dev_at_squid-cache.org
Sent: Tue, December 28, 2010 1:12:08 PM
Subject: Benchmarking results for Squid-3.1.9-20101210

Hi,

I wanted to share some benchmarking results from one of the nodes in live system

running the

3.1.9 build line. I also plan in installing the 3.1.10 line within the next week

after verification of the newer build. I will share the results if the show
improvements.

If you have any questions or comments please feel free to ask.

CPU Intel(R) Xeon(R) CPU L5310 @ 1.60GHz (dual-core)
RAM 8 GB
HDD 1 x 400G SAS
OS Red Hat Enterprise Linux AS release 4 (Nahant Update 4) 32-bit, OS has been
tunned for 32-bit & RHEL

Users 54
RPS 615
Hit Ratio Request 41.7%-42.8% , Byte 49.8.7%-46.9%
CPU Usage 31.69%

Thanks,

Jack
Received on Fri Jan 07 2011 - 15:09:27 MST