How a Curl‑NSS dentry Leak Caused Our Load Balancer’s Memory Spike

Problem Background

Our operations team received alerts that several load‑balancer (LB) instances showed memory usage exceeding 80‑90% and still rising. The LB services handle traffic for retail, logistics, and technology businesses, forwarding tens of thousands of services. To prevent crashes, instances with >90% usage were taken offline while the issue was investigated.

Investigation Process

Developers examined /proc/meminfo and noticed a large Slab allocation, suggesting a possible kernel memory leak.

$ cat /proc/meminfo
MemTotal:       65922868 kB
MemFree:         9001452 kB
...
Slab:           39242216 kB
SReclaimable:   38506072 kB
SUnreclaim:       736144 kB

Running slabtop revealed that dentry objects dominated the slab usage. The team linked the leak to a curl‑based HTTPS health‑check script running on the LB nodes. Research showed that curl 7.19.7, when using the NSS library, suffers from a dentry leak bug.

$ curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 ...

$ rpm -aq | grep nss-
 nss-util-3.16.1-3.el6.x86_64
 nss-sysinit-3.16.1-14.el6.x86_64
 nss-softokn-freebl-3.14.3-17.el6.x86_64
 nss-softokn-3.14.3-17.el6.x86_64
 nss-3.16.1-14.el6.x86_64
 nss-tools-3.16.1-14.el6.x86_64

The fix described in the referenced article is to set the environment variable NSS_SDB_USE_CACHE. The team verified that this resolves the leak.

Solution

1. Stop the probing script immediately and, during low‑traffic periods, clear caches on the affected LB nodes using echo 3 > /proc/sys/vm/drop_caches. 2. After the peak period, modify the script to export NSS_SDB_USE_CACHE=1 before invoking curl, permanently fixing the issue.

Review and Summary

The root cause was a dentry leak in the NSS library used by curl 7.19.7. The health‑check script merely exposed the problem. This incident highlighted the importance of understanding Linux memory management.

Linux Memory Addressing

Linux uses virtual memory. Three address types exist:

Logical address – segment + offset.

Linear (virtual) address – 32‑bit unsigned integer used by processes.

Physical address – actual RAM location.

The MMU converts logical to linear via segmentation, then linear to physical via paging.

Linux Paging Mechanism

Paging splits linear addresses into fixed‑size pages (typically 4 KB). Page frames hold these pages in RAM. The page table maps linear pages to physical frames.

NUMA Architecture

Non‑Uniform Memory Access (NUMA) divides physical memory into nodes, each attached to a set of CPU cores, reducing latency for local memory accesses.

Buddy System Allocation

The kernel uses the buddy algorithm to allocate contiguous page frames, mitigating external fragmentation.

Slab Allocation

Slab allocates memory in object‑sized caches, reducing internal fragmentation. Objects such as dentry are managed by the slab allocator, which obtains pages from the buddy system.

Process Memory Layout

A Linux process memory is divided into five regions:

Text segment – executable code.

Data segment – initialized global/static variables.

BSS segment – uninitialized global/static variables.

Heap – dynamically allocated memory.

Stack – local variables and call frames.

Linux Memory Inspection Tools

free -h

– shows total, used, free, and cached memory. top – displays VIRT, RES, and SHR for processes. cat /proc/<pid>/smaps – detailed per‑mapping memory usage. vmstat – real‑time virtual memory and CPU statistics. /proc/meminfo – comprehensive system memory statistics.

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           31Gi        13Gi       8.0Gi       747Mi        10Gi        16Gi
Swap:          2.0Gi       321Mi       1.7Gi

Understanding these tools and the underlying memory mechanisms helped the team quickly identify and remediate the leak.