Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Agent Dashboard — TCP TIME_WAIT

What this chart shows​

TCP TIME_WAIT — the number of TCP sockets waiting out the 2MSL (2 × Maximum Segment Lifetime) timeout before being fully released, read from /proc/net/sockstat (tw field) on every heartbeat (~30 s + 0–10 s jitter).

TIME_WAIT sockets are a normal part of TCP connection teardown. They exist to prevent delayed packets from a closed connection being confused with packets from a new connection on the same port.

Linux only​

This metric requires /proc/net/sockstat.

How to read it​

Value rangeInterpretation
0–50Normal background level
50–500Post-job drain — expected after a large copy job completes and S3 connections close
> 500 sustainedPossible connection churn — S3 client opening and closing connections too aggressively

TIME_WAIT is normal, not an error​

A spike in TIME_WAIT after a copy job completes is expected: the S3 connection pool closes idle connections, each entering TIME_WAIT for ~60 seconds before the kernel reclaims the port. The chart will show a rise followed by a gradual decay — this is healthy behavior.

When to investigate​

Concern arises when TIME_WAIT count grows continuously without decaying, or when it stays above 1000 between jobs. This can indicate:

  • The S3 client is not reusing connections (keep-alive disabled)
  • The connection pool maxConcurrency is much larger than needed, causing excessive churn
  • The kernel tcp_fin_timeout is set very high on the host

Polling interval​

Sampled on every heartbeat (~30 s + 0–10 s jitter) from the Linux kernel's socket state counters.