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.
