[squid-users] RE: SUN E4000 - comm_accept and http_accept: accept_failure - Answers and Questions

Hi all

Michael Kiernan wrote:

>It looks like this tuning has been done for an
>earlier (most likely solaris 2.6) kernel.
>
>If you _are_ using solaris 8 as mentioned below
>(i missed the earlier part of the thread):
>
>- *remove* the set priority_paging=1, and initially
> at least the other vm tuning (lotsfree etc). Solaris
> 8 has a new paging algorithm (cyclic paging) by
> default which supercedes priority paging. Turning
> on priority paging disables the more advanced cyclic
> paging methodology.
>
Ok, I removed this parameter, Do I need to keep the parameters below ?

set cachefree=191514
set lotsfree=95757
set desfree=47878
set minfree=23939
set fastscan=95757
set slowscan=9575
set handspreadpages=95757
set maxpgio=256

>
>
>- run 'kstat hme' or qfe, or whatever interfaces you
> are using. Alternatively run 'netstat -k' and look
> for the hme/qfe section. Check for any errors such
> as under the 'nocanput' field.
>
It haves many errors...:

module: ge instance: 0
name: ge0 class: net
 
        align_errors 0
        allocbfail 0
        brdcstrcv 247948928
        brdcstxmt 457708
        carrier_errors 0
        collisions 0
        crtime 201.87079031
        defer_timer_exp 0
        defer_xmts 0
        drop 5486747
        ex_collisions 0
        excessive_coll 0
        fcs_errors 0
        first_coll 0
        ge_csumerr 0
        ge_queue_cnt 0
        ge_queue_full_cnt 0
        ierrors 5486750
        ifspeed 1000000000
        inits 73
        ipackets 2697829779
        ipackets64 2697829779
        jabber 0
        late_coll 0
        mac_mode 2
        macrcv_errors 0
        macxmt_errors 0
        multircv 19241570
        multixmt 0
        no_free_rx_desc 1
        no_tmds 0
      nocanput 33397
        nocarrier 5
        norcvbuf 0
        noxmtbuf 0
        obytes 4187123676
        obytes64 1434411233244
        oerrors 0
        opackets 2368950130
        opackets64 2368950130
        pause_off_cnt 0
        pause_on_cnt 0
        pause_rcv_cnt 0
        pause_time_cnt 0
        pci_badack 0
        pci_bus_speed 0
        pci_bus_width 0
        pci_data_parity_err 0
        pci_det_parity_err 0
        pci_dtrto 0
        pci_rcvd_master_abort 0
        pci_rcvd_target_abort 0
        pci_signal_system_err 0
        pci_signal_target_abort 0
        peak_attempt_cnt 0
        rbytes 2962406685
        rbytes64 1269977759005
        rcv_dma_mode 4
        rx_align_err 0
        rx_code_viol_err 0
        rx_crc_err 0
        rx_error_ack 0
        rx_hang 0
        rx_late_error 0
        rx_length_err 1
        rx_overflow 1
        rx_parity_error 0
        rxinits 0
        rxtag_error 0
        slv_error_ack 0
        slv_parity_error 0
        snaptime 8715189.708651
        sqe_errors 0
        toolong_errors 0
        tx_error_ack 0
        tx_late_error 0
        tx_parity_error 0
        txinits 0
        txmac_maxpkt_err 0
        txmac_urun 0
        xmit_dma_mode 6
        xmit_dma_mode 6

>
>
>- run netstat -sP tcp; probably the most relevant field
> here is tcpListenDrop, but look for anything else that
> may look strange.
>
TCP tcpRtoAlgorithm = 4 tcpRtoMin = 2000
        tcpRtoMax = 60000 tcpMaxConn = -1
        tcpActiveOpens =38477983 tcpPassiveOpens =57706164
        tcpAttemptFails = 77672 tcpEstabResets =13965251
        tcpCurrEstab = 731 tcpOutSegs =2084107423
        tcpOutDataSegs =1276907772 tcpOutDataBytes =3261898720
        tcpRetransSegs =3773001 tcpRetransBytes =2954564000
        tcpOutAck =802799874 tcpOutAckDelayed =286920603
        tcpOutUrg = 0 tcpOutWinUpdate =1032309
        tcpOutWinProbe =266018 tcpOutControl =189634741
        tcpOutRsts =11654200 tcpOutFastRetrans =857535
        tcpInSegs =2382788778
        tcpInAckSegs =907353630 tcpInAckBytes =2138015618
        tcpInDupAck =173153374 tcpInAckUnsent = 0
        tcpInInorderSegs =1201452004 tcpInInorderBytes =4019774889
        tcpInUnorderSegs =2813668 tcpInUnorderBytes =2506219118
        tcpInDupSegs =3156755 tcpInDupBytes =680255157
        tcpInPartDupSegs = 10780 tcpInPartDupBytes =5182246
        tcpInPastWinSegs = 370 tcpInPastWinBytes =1329380830
        tcpInWinProbe =1492216 tcpInWinUpdate =243156
        tcpInClosed =4162233 tcpRttNoUpdate =2084514
        tcpRttUpdate =848049216 tcpTimRetrans =4960082
        tcpTimRetransDrop = 19040 tcpTimKeepalive = 5455
        tcpTimKeepaliveProbe= 1863 tcpTimKeepaliveDrop = 1
        tcpListenDrop = 0 tcpListenDropQ0 = 0
        tcpHalfOpenDrop = 0 tcpOutSackRetrans =295849

I am confuse.....

>
>
>There's some good basic info about this kind of thing at:
>http://www.sean.de/Solaris/tune.html
>
Some configurations I geting from this site, Is really very good...

>
>
>If your tcp stack is stuffed, you can tune it to cope,
>or almost cope with your high watermarks, but in the
>longterm you may want to look at spreading the load
>over more network interfaces [maybe have a look at
>Solaris 8 IP multipathing]
>
>- Mike
>
Now, I use only a Gigabit Ethernet...and I don't have an other Gigabit
Interface...., but this is a good idea...!

Thanks in advance

Best Regards

_________________________________________
 Hederson Velasco Ramos
 Technology Consultant
 Email: hederson.ramos@edb.ericsson.se
 EIN - Network Services - Ericsson - EDB

>
>
>>Hi All,
>>
>> Thanks for all...,
>>
>>Mail from: Adam Carter
>>
>>>Have you tweaked solaris's kernel in the same way on both boxes?
>>>Solaris 8
>>>has tons of kernel parameters you can modify, perhaps you are
>>>running out of
>>>some resource (check the logs), or just not optimally tuned. I know
>>>the
>>>default config left many of our busier boxes starved. None of these
>>>were
>>>dedicated squid boxes, but its still worth investigating. Let me
>>>know if you
>>>want more info on this and i'll dig up the configs.
>>>Adam
>>>
>>This is the tune that has in the e4000 box...
>>
>>set rlim_fd_cur=65535
>>set rlim_fd_max=65535
>>*
>>*
>>* Tunning for squid diskd
>>set msgsys:msginfo_msgmax=2049
>>set msgsys:msginfo_msgmnb=8192
>>set msgsys:msginfo_msgssz=64
>>set msgsys:msginfo_msgtql=1024
>>*
>>*
>>* Tunning for Solaris 8 - From Sun Microsystems
>>set shmsys:shminfo_shmmax=524288000
>>set shmsys:shminfo_shmmin=1
>>set shmsys:shminfo_shmmni=100
>>set shmsys:shminfo_shmseg=10
>>set semsys:seminfo_semmnu=50
>>set semsys:seminfo_semmap=100
>>*
>>set semsys:seminfo_semmni=200
>>set semsys:seminfo_semmns=1000
>>set semsys:seminfo_semmsl=100
>>set msgsys:msginfo_msgmni=50
>>set lwp_default_stksize=0x4000
>>set rpcmod:svc_run_stksize=0x4000
>>*
>>set priority_paging=1
>>set cachefree=191514
>>set lotsfree=95757
>>set desfree=47878
>>set minfree=23939
>>set fastscan=95757
>>set slowscan=9575
>>set handspreadpages=95757
>>set maxpgio=256
>>
>>TCP TUNE...
>>
>>/usr/sbin/ndd -set /dev/tcp tcp_conn_hash 262144
>>/usr/sbin/ndd -set /dev/ge adv_1000autoneg_cap 0
>>/usr/sbin/ndd -set /dev/ge adv_1000fdx_cap 1
>>/usr/sbin/ndd -set /dev/ge adv_1000hdx_cap 0
>>/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 65535
>>/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 65535
>>/usr/sbin/ndd -set /dev/tcp tcp_cwnd_max 65535
>>#
>>/usr/sbin/ndd -set /dev/tcp tcp_slow_start_initial 2
>>/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000
>>/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024
>>/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 131072
>>/usr/sbin/ndd -set /dev/tcp tcp_wscale_always 1
>>/usr/sbin/ndd -set /dev/tcp tcp_max_buf 504857600/usr/sbin/ndd -set
>>/dev/tcp tcp_smallest_anon_port 8192
>>/usr/sbin/ndd -set /dev/udp udp_smallest_anon_port 8192
>>/usr/sbin/ndd -set /dev/tcp tcp_rexmit_interval_min 2000 # 200 for
>>laboratories
>>/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 600000 # 10 min
>>before drop
>>/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 60000 # 60 sec
>>to estab. conn.
>>/usr/sbin/ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500
>>
>>Mail from: joelja@darkwing.uoregon.edu
>>
>>Given the fact that the main squid process is only gonna sit on a
>>single
>>cpu I'd say an e4000 might be a little oddly sized as squid box... if
>>the
>>e250 had the 300 or 400mhz ultra IIi cpu's I could see it
>>outperforming an
>>e4000 even though the larger machine has a lot more cpu cache, given
>>the
>>amount of ram you have and the fact that e4000 have fibre channel
>>controllers built-in I'd be inclinded to aim for a 100GB or so of
>>cache
>>dir. squeezing more performance out of the box might also involve
>>running
>>more than one instance of squid, and point some of the clients at one
>>and
>>some at the other...
>>I understand..., but I have some questions:
>>
>>Do you mean: Running one instance of Squid per CPU?
>>Do you mean: An e250 is better than a e4000 to run Squid?
>>
>>Mail from: vanzyla@cedara.kzntl.gov.za
>>
>>What kind of load does the server carry?
>>
>>Only run squid with user authentication...
>>
>>How many file descriptors are configured on your box?
>>
>>In Solaris Operation System are running with 65535 and in the squid
>>are running with 32768 (I think that are the max value for squid...).
>>
>>AD
>>
>>__________________________________________________________________________________________________________________
>>
>>Do you have any idea to solve this problem ?
>>
>>Thanks in advance
>>
>>Best Regards
>>
>>--
>>_________________________________________
>> Hederson Velasco Ramos
>> Technology Consultant
>> Email: hederson.ramos@edb.ericsson.se
>> EIN - Network Services - Ericsson - EDB
>>
>

--