Search squid archive

Re: is there any thing wrong from cache manager logs ?!!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux