Author: Danilo

Troubleshoot packet drops on ESXi by first identifying where packet loss occurs in the virtual and physical network path. A problem that appears to involve a physical NIC may actually be caused by a virtual switch, VMXNET3 queue, CPU contention, VLAN configuration, MTU mismatch, or an upstream physical switch. The first goal is not to collect every possible counter. It is to identify where packets enter the host, where they should leave, and at which point the counters or captures stop matching. This prevents unnecessary changes and helps separate an ESXi problem from a guest operating system or physical network…

When SlurmDBD is down in a Slurm HPC cluster, the impact can look more serious than it actually is. SlurmDBD is central to persistent accounting and account-management data, but it is not the daemon that directly schedules jobs or controls compute nodes during normal cluster operation. That distinction matters during an outage. If slurmctld was already running and had previously synchronized with SlurmDBD, the controller can usually continue operating from cached association, limit, and fair-share information while accounting messages accumulate locally for later delivery. The situation becomes more critical when SlurmDBD remains unavailable for an extended period, administrators need database-backed…

Slurm jobs stuck in COMPLETING state can indicate that one or more compute nodes have not finished cleaning up the resources associated with a workload. In a healthy Slurm-managed HPC cluster, a job normally moves from RUNNING to COMPLETING and then quickly reaches a final state such as COMPLETED, FAILED, or CANCELLED. The COMPLETING phase is expected, but it should usually be brief. When a job remains there for several minutes or longer, Slurm may still be waiting for processes to terminate, an epilog script to finish, a filesystem operation to return, or communication with a compute node to recover.…

Linux swap usage can sometimes look confusing, especially when a server still has several gigabytes of available memory. At first glance, this may seem like a sign of memory pressure or poor system performance. In reality, Linux memory management is designed to use RAM efficiently rather than keep swap permanently at zero. The kernel may move inactive pages to swap even when physical memory is still available. Understanding Linux swap usage requires looking beyond the amount of free memory. Swap activity, available RAM, page faults, workload behavior, and kernel settings provide a much clearer picture of what is actually happening.…

Packet loss troubleshooting can become difficult because the symptoms often look similar regardless of where the problem actually occurs. A slow application, unstable SSH session, failed API request, or poor storage performance may all eventually lead an administrator to suspect that packets are being dropped somewhere along the communication path. The real challenge in packet loss troubleshooting is not simply proving that packets are being lost, but determining where the loss happens. A Linux server can lose packets because of local interface errors, overloaded queues, kernel processing limits, switch problems, upstream congestion, firewall behavior, or issues much farther away from…

TCP retransmissions on Linux are a normal part of TCP communication, but an excessive number of retransmitted packets often indicates a problem somewhere between the application and the remote endpoint. Packet loss, congestion, overloaded systems, faulty interfaces, bad cabling, MTU mismatches, and unstable network paths can all produce similar symptoms. When investigating TCP retransmissions on Linux, the challenge is rarely detecting that retransmissions exist. The real task is determining where they originate, whether they are occasional or persistent, and whether they are affecting application performance. Looking at only one command usually provides an incomplete picture. A useful investigation combines kernel…