OK so back to the issue in hands.
it's not squid directly and there is not much load on the server since
the sockets in use are about 3-4k.
I will need the output of:
cat /proc/net/sockstat
cat /proc/net/sockstat6
Which will make it clear that it is either is or not the basic sockets
issue.
Next thing after that is:
Strange OS logs?
also another thing we will might get a clue is tcp tunings.
sysctl -a |grep tcp
As I told you in the chat there are couple major things to consider.
the sysctl values that I was talking about from a machine that knows to
work with 1GB ram and can take some load until now.
# sysctl -a |grep tcp
net.ipv4.tcp_abc = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_adv_win_scale = 1
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_challenge_ack_limit = 100
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_cookie_size = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_early_retrans = 2
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_fack = 1
net.ipv4.tcp_fastopen = 0
net.ipv4.tcp_fastopen_key = 2cc99571-9aad9d28-8b81bbcc-48a576b6
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_limit_output_bytes = 131072
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_max_orphans = 4096
net.ipv4.tcp_max_ssthresh = 0
net.ipv4.tcp_max_syn_backlog = 128
net.ipv4.tcp_max_tw_buckets = 4096
net.ipv4.tcp_mem = 22593 30127 45186
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_sack = 1
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_syn_retries = 6
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_thin_dupack = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_tw_rtcpecycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.tcp_workaround_signed_windows = 0
##END
I have seen couple tunings in the past like:
https://www.jcputter.co.za/centos/squid-proxy-optimization-tweaks/
But I never needed to actually use them.
There is a nice doc from IBM:
ftp://public.dhe.ibm.com/linux/pdfs/Tuning_for_Web_Serving_on_RHEL_64_KVM.pdf
Which I have seen but never completed to fully read and understood yet.
In page 16 there is a nice way to adjust a webserver in the size like
the machines mentioned in page 11+12.
It adds to a machine with:
24 cores
about 90GB of ram and correct me if I am wrong.
http://www.cyberciti.biz/files/linux-kernel/Documentation/networking/ip-sysctl.txt
Has some nice description of each value which should be considered
before deciding on a drastic change.
If you did any changes to any of these OS variables please share any of
them so we would maybe understand what is happening.
This is where RESTART is considered a nice move that will force the os
to defaults (plus considering /etc/sysctl.conf modifications).
I do know that you have self compiled kernel on\for CentOS 6.4.
The current one from CentSO branch is 2.6.X.
Newer kernel can give lots of things if built right.
If you have used a specific way to build the kernel I will be happy to
see it or at-least the .config for this kernel build.
Thanks,
Eliezer
On 11/08/2013 01:29 AM, Dr.x wrote:
> hi amos , im not talkign about t the difference in , out ,
> im wondering why the "in" is higher than "out" ???
>
> shouldnt the "out" higher than "in" ( as a result of hit ration) ?????
>
> i mean if i want to calculate wt im saving , i say (out-in)but in my case
> its in -ve !!!!
>
> i have another good squid machines and they have out valuse more higher
> than in vlause ??!!
>
>
>
> regards
Received on Fri Nov 08 2013 - 20:15:44 MST
This archive was generated by hypermail 2.2.0 : Sat Nov 09 2013 - 12:00:05 MST