How a Misconfigured NIC RX/TX Buffer Caused Intermittent Slowdowns in a GBase 8a Cluster

In a gbase database MPP environment, massive inter‑node data transfers are routine. When the NIC's RX (receive) and TX (transmit) ring buffers are too small, packets get dropped under high load. The symptom is unmistakable: the same SQL that normally finishes in seconds suddenly takes hundreds of seconds, then mysteriously recovers. This article documents a real‑world case where we traced severe performance jitter to an undersized NIC buffer and fixed it permanently.

Symptom

A set of business queries exhibited sudden, drastic performance degradation. A query that typically completed in 10 seconds would sporadically spike to over 200 seconds. The slowdown was not gradual — it was a cliff. When it happened, a whole batch of queries were affected simultaneously. Most of the time, performance returned to normal on its own, which made the problem particularly frustrating to diagnose.

Diagnosis

1. Find the Straggling Node

In an MPP cluster, the slowest node dictates the overall query time. Use the following SQL to check which data node is holding long‑running queries.

SELECT NODE_NAME, ID, user, host, command, start_time, time, state,
       substring(info,0,100) info
FROM information_schema.GNODES_TASK_INFORMATION
WHERE command='query' AND info is not null
  AND info not like '%information_schema.processlist%'
ORDER BY time DESC LIMIT 10;

2. Check the NIC Statistics on the Affected Node

Log into the node identified in the previous step and examine the NIC's RX/TX counters with ifconfig -a <interface>.

• Healthy node: The dropped counter under RX is zero or remains stable over time.
• Problematic node: The dropped counter is slowly but continuously increasing.

dropped means the NIC successfully received a packet but the system could not deliver it to the protocol stack because of insufficient buffer space. This is a software‑level drop, distinct from hardware‑level overruns.

3. Inspect the NIC Ring Buffer Size

Use ethtool -g to check the current ring buffer configuration.

[root@vm161 ~]# ethtool -g enp0s3
Ring parameters for enp0s3:
Pre-set maximums:
RX:                     4096
TX:                     4096
Current hardware settings:
RX:                     256
TX:                     256

The hardware supports up to 4096 entries for both RX and TX, yet the current setting was a mere 256 — far too small for an MPP database's bursty, high‑throughput traffic.

Solution

Scale the ring buffers up to the maximum supported value with ethtool -G.

[root@vm161 ~]# ethtool -G enp0s3 rx 4096 tx 4096
[root@vm161 ~]# ethtool -g enp0s3
...
Current hardware settings:
RX:                     4096
TX:                     4096

After applying this change, the dropped counter on the affected node stopped incrementing. Over the following days, all queries maintained stable execution times, and the periodic jitter that had plagued the cluster was eliminated.

Key Takeaway

Network‑layer tuning is just as important as database parameter tuning in a gbase database cluster. Always set the NIC ring buffer to its maximum supported size during deployment. This simple step prevents a whole class of intermittent performance problems that are otherwise extremely difficult to diagnose. When a query suddenly slows down, don't just look at the SQL — check the network interface counters too.