Eliezer Croitoru-2 wrote
> 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
HI ,
1st of all thanks alot for interest and help to last step
actually my problem wasnt due to cpu or ram ,
it was due to kernel ,
u mentioned the kernel logs >>>> about that u were 100 % right
my kernel logs says :
*TCP: out of memory -- consider tuning tcp_mem*
which is found by huge numbers ,
revising my sysctl , it was found that there were a mistake and corrected by
changing the tcpmem value to another bigger vlaue so that it support large
number of tcp mem requests
in sysctl , was edited by =====>net.ipv4.tcp_mem = 6085248 8113664 12170496
i know it is very huge relative to small number of users , but i thibnk i
will use it when i migrate my work to bigger machine
in summary , and so that we dont make more conflict for readers this post :
the problem was in kernel ! , and the solution was tuniing net.ipv4.tcp_mem
value .
many thanks to Eliezer ,Amos, Alex .
i also would like to flag this post as "solved " for readers .
regards
-----
Dr.x
-- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/is-there-any-thing-wrong-from-cache-manager-logs-tp4663156p4663196.html Sent from the Squid - Users mailing list archive at Nabble.com.Received on Sat Nov 09 2013 - 18:23:14 MST
This archive was generated by hypermail 2.2.0 : Sat Nov 09 2013 - 12:00:05 MST