how to reduce FIN_WAIT and TIME_WAIT - TCP-IP

This is a discussion on how to reduce FIN_WAIT and TIME_WAIT - TCP-IP ; in my linux server, after runing the command "netstat -an|awk '/tcp/ {print $6}'|sort| uniq -c " I got the result below: 10 CLOSE_WAIT 784 CLOSING 1886 ESTABLISHED 5825 FIN_WAIT1 2070 FIN_WAIT2 985 LAST_ACK 11 LISTEN 419 SYN_RECV 5653 TIME_WAIT I ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: how to reduce FIN_WAIT and TIME_WAIT

  1. how to reduce FIN_WAIT and TIME_WAIT

    in my linux server,
    after runing the command "netstat -an|awk '/tcp/ {print $6}'|sort|
    uniq -c "
    I got the result below:

    10 CLOSE_WAIT
    784 CLOSING
    1886 ESTABLISHED
    5825 FIN_WAIT1
    2070 FIN_WAIT2
    985 LAST_ACK
    11 LISTEN
    419 SYN_RECV
    5653 TIME_WAIT

    I think there should be too many TIME_WAIT and FIN_WAIT, isn't? can
    anyone do me a favor, thanks a lot.

  2. Re: how to reduce FIN_WAIT and TIME_WAIT

    On Nov 2, 11:18*pm, Jayson wrote:
    > in my linux server,
    > after *runing the command "netstat -an|awk '/tcp/ {print $6}'|sort|
    > uniq -c "
    > I got the result below:
    >
    > * 10 CLOSE_WAIT
    > * * 784 CLOSING
    > * *1886 ESTABLISHED
    > * *5825 FIN_WAIT1
    > * *2070 FIN_WAIT2
    > * * 985 LAST_ACK
    > * * *11 LISTEN
    > * * 419 SYN_RECV
    > * *5653 TIME_WAIT
    >
    > I think there should be too many TIME_WAIT and FIN_WAIT, isn't? can
    > anyone do me a favor, thanks a lot.


    There's no way to judge whether this is too many without knowing what
    the server is doing. If this is a server that deals with a high-rate
    of connect/disconnect cycles, these numbers are perfectly reasonable.
    Given that you have 784 CLOSING and 419 SYN_RECV connections, the
    numbers in the various other states seems reasonable.

    Is something wrong? What does this machine do?

    DS

  3. Re: how to reduce FIN_WAIT and TIME_WAIT

    Jayson wrote:
    > in my linux server,
    > after runing the command "netstat -an|awk '/tcp/ {print $6}'|sort|
    > uniq -c "
    > I got the result below:


    > 10 CLOSE_WAIT
    > 784 CLOSING
    > 1886 ESTABLISHED
    > 5825 FIN_WAIT1
    > 2070 FIN_WAIT2
    > 985 LAST_ACK
    > 11 LISTEN
    > 419 SYN_RECV
    > 5653 TIME_WAIT


    > I think there should be too many TIME_WAIT and FIN_WAIT, isn't? can
    > anyone do me a favor, thanks a lot.


    Looks fine to me. FIN_WAIT_1 is an active retransmission state and
    will go away on its own. TIME_WAIT is there as part of TCP's
    correctness algorithms and unless you are _REALLY_ memory constrained
    5600 of them isn't that much.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  4. Re: how to reduce FIN_WAIT and TIME_WAIT

    thanks David,
    as you say, the machine is a high-rate web server,

    the problem is that the main page of the website displays in a really slow rate, about 1.5min, and the main page is only 234kb with all the images.


    Quote Originally Posted by David Schwartz View Post
    On Nov 2, 11:18*pm, Jayson wrote:
    > in my linux server,
    > after *runing the command "netstat -an|awk '/tcp/ {print $6}'|sort|
    > uniq -c "
    > I got the result below:
    >
    > * 10 CLOSE_WAIT
    > * * 784 CLOSING
    > * *1886 ESTABLISHED
    > * *5825 FIN_WAIT1
    > * *2070 FIN_WAIT2
    > * * 985 LAST_ACK
    > * * *11 LISTEN
    > * * 419 SYN_RECV
    > * *5653 TIME_WAIT
    >
    > I think there should be too many TIME_WAIT and FIN_WAIT, isn't? can
    > anyone do me a favor, thanks a lot.


    There's no way to judge whether this is too many without knowing what
    the server is doing. If this is a server that deals with a high-rate
    of connect/disconnect cycles, these numbers are perfectly reasonable.
    Given that you have 784 CLOSING and 419 SYN_RECV connections, the
    numbers in the various other states seems reasonable.

    Is something wrong? What does this machine do?

    DS

  5. Re: how to reduce FIN_WAIT and TIME_WAIT

    thanks rick,

    if all the things going right, then why my server loading page slowly, about 1.5min to load the main page which is only 234kb.

    Quote Originally Posted by Rick Jones View Post
    Jayson wrote:
    > in my linux server,
    > after runing the command "netstat -an|awk '/tcp/ {print $6}'|sort|
    > uniq -c "
    > I got the result below:


    > 10 CLOSE_WAIT
    > 784 CLOSING
    > 1886 ESTABLISHED
    > 5825 FIN_WAIT1
    > 2070 FIN_WAIT2
    > 985 LAST_ACK
    > 11 LISTEN
    > 419 SYN_RECV
    > 5653 TIME_WAIT


    > I think there should be too many TIME_WAIT and FIN_WAIT, isn't? can
    > anyone do me a favor, thanks a lot.


    Looks fine to me. FIN_WAIT_1 is an active retransmission state and
    will go away on its own. TIME_WAIT is there as part of TCP's
    correctness algorithms and unless you are _REALLY_ memory constrained
    5600 of them isn't that much.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  6. Smile Re: how to reduce FIN_WAIT and TIME_WAIT

    Any body knows in this condition,
    about how much concurrency this machine is handling with.

    I'm a newbie to those numbers..

    thanks a lot

    Quote Originally Posted by Jayson View Post
    in my linux server,
    after runing the command "netstat -an|awk '/tcp/ {print $6}'|sort|
    uniq -c "
    I got the result below:

    10 CLOSE_WAIT
    784 CLOSING
    1886 ESTABLISHED
    5825 FIN_WAIT1
    2070 FIN_WAIT2
    985 LAST_ACK
    11 LISTEN
    419 SYN_RECV
    5653 TIME_WAIT

    I think there should be too many TIME_WAIT and FIN_WAIT, isn't? can
    anyone do me a favor, thanks a lot.

+ Reply to Thread