How to Inspect and Monitor Network Socket Memory Buffers in Linux Using the ss Command

High-throughput Linux network servers—such as reverse proxies, distributed databases, and video streaming endpoints—often experience latency spikes or dropped connections without any visible CPU or disk bottlenecks. In many instances, the root cause lies within kernel socket memory exhaustion. When an application cannot process incoming packets quickly enough, or when remote network recipients fail to acknowledge outgoing data, TCP socket buffers fill to capacity. Once the allocated buffer limit is breached, the Linux kernel silently discards packets. While legacy administrators relied on the obsolete netstat tool, modern Linux kernels expose precise socket buffer allocations via the ss (Socket Statistics) utility and kernel virtual filesystems.

Understanding Linux Socket Send and Receive Buffers

Every active network socket maintains two primary memory queues allocated from kernel memory:

• Receive Queue (Recv-Q): For established TCP connections, this represents the volume of data in bytes that the kernel network stack has received from the network interface card (NIC) and acknowledged, but which the user-space application has not yet retrieved via read() or recv().
• Send Queue (Send-Q): For established connections, this represents the volume of unacknowledged data in bytes currently residing in memory waiting for remote ACK responses or transmission across the wire.
• Listening Sockets Exception: For sockets in the LISTEN state, Recv-Q indicates the current number of completed connections waiting in the accept queue (backlog), while Send-Q denotes the maximum backlog threshold defined by the application.

Inspecting Active Socket Buffers with ss

The ss command interfaces directly with kernel netlink sockets, providing instantaneous reporting without the heavy performance penalties associated with parsing /proc/net/tcp.

1. Inspecting Listening Sockets and Backlog Queues

To verify whether daemon listening queues (such as Nginx on port 80 or PostgreSQL on port 5432) are overflowing under load, execute:

ss -lnt

Sample output:

State      Recv-Q Send-Q  Local Address:Port   Peer Address:Port
LISTEN     0      128     0.0.0.0:22           0.0.0.0:*
LISTEN     128    128     0.0.0.0:80           0.0.0.0:*

Diagnostic Alert: If Recv-Q equals Send-Q on a listening socket (as seen on port 80 above), the accept queue is completely saturated! New incoming TCP connection handshakes (SYN-ACK) will be dropped or reset.

2. Exposing Detailed Memory Usage with ss -m

To inspect physical memory structures allocated to individual connections, pass the -m (memory) flag alongside established socket filters:

ss -tmi 'sport = :443'

The resulting output exposes low-level kernel memory descriptors for each socket:

ESTAB      0      14600   192.168.1.50:443     10.0.0.12:54890
     skmem:(r0,rb131072,t14600,tb262144,f0,s0,w0,o0,bl0,d0)
     cubic wscale:7,7 rto:204 rtt:0.12/0.04 ato:40 mss:1460 rcvspace:131072 ssthresh:10 cwnd:10

Interpreting the skmem Memory Fields:

• r: Actual data bytes currently queued in the receive buffer.
• rb: Receive buffer memory limit (in bytes) allocated by TCP autotuning.
• t: Actual data bytes currently queued in the transmit (send) buffer.
• tb: Transmit buffer memory limit (in bytes).
• f: Forward allocated memory cache for this socket.
• w: Memory committed to waiting write operations.
• d: Discarded bytes due to socket queue exhaustion.

Auditing System-Wide Socket Allocations via sockstat

While ss profiles individual sockets, monitoring aggregate memory pressure across the entire operating system is achieved through /proc/net/sockstat:

cat /proc/net/sockstat

Sample output:

sockets: used 1240
TCP: inuse 85 orchestrating 12 alloc 102 mem 1420
UDP: inuse 18 mem 4
RAW: inuse 0
FRAG: inuse 0 memory 0

Note: The mem value represents memory measured in kernel memory pages (typically 4096 bytes per page on x86_64 systems). To convert to megabytes: (mem * 4096) / (1024 * 1024).

Tuning Kernel Buffer Thresholds in sysctl.conf

If analysis indicates frequent buffer exhaustion under heavy load, tune Linux autotuning parameters inside /etc/sysctl.conf:

# Increase maximum network socket receive and send limits (in bytes)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# Configure TCP autotuning boundaries: min, default, max
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Increase maximum backlog accept queue length
net.core.somaxconn = 4096

Apply changes immediately without rebooting:

sudo sysctl -p

Regularly auditing socket buffers with ss -m ensures production Linux servers maintain peak network performance and eliminates mystery packet drops caused by queue saturation.