Tuning XFS Inode Caches for High-Density Portfolio Imagery

The deployment environment involves a multi-tenant WordPress cluster running on Debian 12, utilizing a localized XFS filesystem on NVMe storage. The primary workload consists of the Angel – Fashion Model Agency WordPress CMS Theme, a product designed for high-resolution model portfolios. This specific use case generates an atypical metadata load. Unlike standard blog-centric sites, this agency platform maintains over 80,000 individual JPEG assets, each requiring multiple cropped thumbnails for various viewport breakpoints (Retina, mobile, tablet, and gallery previews).

During a routine performance audit using iostat -xz 1, I observed an elevated await time on the NVMe device during media library imports, despite the util% remaining under 15%. This discrepancy suggested that the bottleneck was not physical I/O bandwidth or saturation, but rather a latency issue within the filesystem’s metadata handling or the kernel's Virtual File System (VFS) layer.

The Diagnostic Path: slabtop and vmstat -m

Standard monitoring tools failed to explain why the wp_generate_attachment_metadata function was taking 400ms longer than baseline. I avoided higher-level tracing and went straight to the kernel slab allocator metrics. Running slabtop -o revealed that the xfs_inode and dentry caches were the top consumers of memory, which is expected. However, the obj/slab ratio for xfs_inode was significantly lower than on other nodes. Specifically, the system was holding 450,000 inodes in memory, but the active percentage was fluctuating wildly.

By executing vmstat -m, I could see the memory allocation for xfs_ili (XFS Inode Log Item) and xfs_buf. The fragmentation in these slabs indicated that the kernel was frequently reclaiming and then immediately re-allocating inode objects. This cycle, known as cache thrashing, occurs when the kernel's memory management (kswapd) decides that the VFS cache is less important than the page cache or application memory.

In a fashion agency context, the Angel theme frequently queries the wp_posts table for attachments while simultaneously checking the existence of physical files via file_exists() in the _wp_relative_upload_path utility. When comparing this with a Download WooCommerce Theme profile, which typically has more balanced I/O between database and files, the Angel theme is heavily skewed toward filesystem metadata operations.

XFS Allocation Groups and Metadata Latency

XFS divides a partition into Allocation Groups (AGs). Each AG is effectively an independent sub-filesystem with its own inode management and free space tracking. For this deployment, I checked the AG count using xfs_info /var/www. The partition was initialized with 4 AGs—the default for a smaller volume.

The problem with a low AG count in high-density imagery environments is lock contention. When PHP-FPM workers are concurrently writing thumbnails to the same uploads/year/month directory, they are competing for the same AGI (Inode) and AGF (Free space) locks within a single AG. This creates a queue at the kernel level that does not show up as high CPU usage but manifests as "jitter" in script execution time.

The Role of vm.vfs_cache_pressure

The Linux kernel has a tunable parameter, vm.vfs_cache_pressure, which defaults to 100. This value controls the tendency of the kernel to reclaim memory used for caching of directory and inode objects. At 100, the kernel reclaims VFS caches at the same rate as the page cache and swap.

For the Angel theme, the metadata is arguably more critical for responsiveness than the actual file content (page cache). If a thumbnail's inode is evicted from RAM, the next request must perform a synchronous read from the NVMe just to locate the file, even if the file's data is still in the page cache. I monitored this by looking at /proc/sys/vm/vfs_cache_pressure and the kswapd0 activity logs in dmesg. The kernel was aggressively pruning the dentry cache to make room for anonymous memory used by ImageMagick during the cropping process.

Memory Fragmentation in the PHP-FPM Slab

The imagick extension, used by the theme to process high-resolution model photos, allocates memory in large chunks. On this system, these allocations were forcing the kernel into direct reclaim mode. When the kernel enters direct reclaim, it halts the requesting process until it can find free memory pages. This was the "cold" cause of the 400ms latency spikes.

I analyzed the RSS of the PHP-FPM pool. Each worker was consuming roughly 120MB during an image upload. By reducing the vfs_cache_pressure, I instructed the kernel to prioritize the inode cache over the page cache, ensuring that the directory structure of the fashion portfolio remained resident in RAM.

Implementation and Tuning

To resolve the metadata contention, I re-evaluated the mount options. Using noatime is mandatory, but for this specific fashion model agency site, I also added nodiratime and adjusted the logbsize.

# /etc/fstab entry for the uploads volume
UUID=... /var/www/uploads xfs defaults,noatime,nodiratime,logbsize=256k,logbufs=8 0 2

The logbsize=256k increases the size of the in-memory filesystem log buffer, reducing the frequency of synchronous log flushes to disk when thousands of thumbnails are being created and unlinked.

Next, I tuned the kernel parameters to stabilize the VFS cache:

# System-wide tuning
sysctl -w vm.vfs_cache_pressure=50
sysctl -w vm.dirty_background_ratio=5
sysctl -w vm.dirty_ratio=20

By setting vfs_cache_pressure to 50, I effectively halved the kernel's desire to reclaim inodes compared to other cache types. This resulted in the xfs_inode count in slabtop stabilizing at 600,000 without the constant fluctuations observed previously.

Final Verification

Post-tuning, I utilized perf stat to monitor the context-switch rate during a batch upload of 200 model portraits. The number of context-switches dropped by 40%, and the iowait remained at 0.00%. The Angel theme's gallery generation now maintains a steady 120ms response time per asset.

Always monitor the SReclaimable and SUnreclaim values in /proc/meminfo. If SUnreclaim is climbing, you have a slab leak. If SReclaimable is high but your dentry cache is small, your vfs_cache_pressure is too high for your metadata-heavy workload. Stop using default filesystem settings for media-intensive CMS deployments.