- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Question about tcp_keepalive_interval (user se...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2016 06:15 AM
тАО06-24-2016 06:15 AM
Re: Question about tcp_keepalive_interval (user sessions dropping)
Thanks for the links to the white papers. WIll give them a read. This server barely gets any use- 18 users max- which is another reason why I don't get why the remote user sessions drop.. It isn't from a heavy load.
Will keep track of netstat -s and keep an eye on the certain interesting numbers you mentioned.
Here's a fresh one from today, June 24-
------------------------------------------------------------------------------------------------------------------------
tcp:
4546858 packets sent
3285808 data packets (807571499 bytes)
39086 data packets (5025188 bytes) retransmitted
1261252 ack-only packets (1184862 delayed)
0 URG only packets
0 window probe packets
2 window update packets
452435 control packets
4127369 packets received
2651991 acks (for 810062267 bytes)
1651 duplicate acks
0 acks for unsent data
2323447 packets (237362168 bytes) received in-sequence
1 completely duplicate packet (119 bytes)
89 packets with some dup, data (33129 bytes duped)
8339 out of order packets (5251771 bytes)
27 packets (3284241333 bytes) of data after window
0 window probes
17433 window update packets
18 packets received after close
7 segments discarded for bad checksum
0 bad TCP segments dropped due to state change
60942 connection requests
17996 connection accepts
78938 connections established (including accepts)
125648 connections closed (including 46724 drops)
45686 embryonic connections dropped
2480824 segments updated rtt (of 2480824 attempts)
216572 retransmit timeouts
45582 connections dropped by rexmit timeout
0 persist timeouts
162795 keepalive timeouts
156413 keepalive probes sent
149 connections dropped by keepalive
0 connect requests dropped due to full queue
2159 connect requests dropped due to no listener
0 suspect connect requests dropped due to aging
0 suspect connect requests dropped due to rate
udp:
0 incomplete headers
0 bad checksums
0 socket overflows
ip:
4405083 total packets received
0 bad IP headers
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets forwarded
0 packets not forwardable
icmp:
79 calls to generate an ICMP error message
0 ICMP messages dropped
Output histogram:
echo reply: 78
destination unreachable: 1
source quench: 0
routing redirect: 0
echo: 0
time exceeded: 0
parameter problem: 0
time stamp: 0
time stamp reply: 0
address mask request: 0
address mask reply: 0
0 bad ICMP messages
Input histogram:
echo reply: 56777
destination unreachable: 14
source quench: 0
routing redirect: 0
echo: 78
time exceeded: 0
parameter problem: 0
time stamp request: 0
time stamp reply: 0
address mask request: 0
address mask reply: 0
78 responses sent
igmp:
0 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with incorrect fields(s)
0 membership reports received
0 membership reports received with incorrect field(s)
0 membership reports received for groups to which this host belongs
0 membership reports sent
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-24-2016 07:44 AM
тАО06-24-2016 07:44 AM
Re: Question about tcp_keepalive_interval (user sessions dropping)
I don't like that you have tcp checksums....but the number is so low that it's likely the "frankengram" scenario....
Your re-transmit rate is about 4% which may be enough for this application to have issues. I still urge you to raise this with your networking team. Perhaps they can do some tuning on their side.....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-27-2016 06:12 AM
тАО06-27-2016 06:12 AM
Re: Question about tcp_keepalive_interval (user sessions dropping)
I think the problem is on the network at the remote location, the user's PC, or something with the Hummingbird Host Explorer software. I just don't see anything on the Unix server I can fix to help with this.
Learned a lot about netstat and ndd though, so thanks everyone!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-28-2016 02:01 AM
тАО06-28-2016 02:01 AM
Re: Question about tcp_keepalive_interval (user sessions dropping)
https://confluence.eits.uga.edu/display/HDSH/Hummingbird+Issues
has the description to set up keepalive signal to be sent from the client side under "Keep Alive Signal" section. This would be the perfect solution, I suppose, though tcp_keepalive_interval can be set upto 10*24*3600000.
If this action is set by the Hmmingbird side, then, you'll never get the session timed out.
- « Previous
-
- 1
- 2
- Next »