Optimizing NFS Configuration for Low-Latency Developer Workloads (Eclipse/VS Code over NFS)


2 views

When developers use IDEs like Eclipse or Visual Studio Code with workspaces mounted via NFS, latency becomes critical. Traditional NFS configurations prioritize throughput over responsiveness, causing frustrating delays in:

  • File operations (save/load)
  • Code indexing
  • Project rebuilds
  • Version control operations

Here's the optimal configuration for /etc/exports on the NFS server:


# /etc/exports
/workspaces 192.168.1.0/24(rw,async,no_wdelay,no_subtree_check,no_root_squash)

Essential mount options for clients:


# /etc/fstab
nfs-server:/workspaces /mnt/workspace nfs rw,hard,intr,noatime,nodiratime,vers=3,tcp,rsize=32768,wsize=32768 0 0

For Linux servers, adjust these sysctl parameters in /etc/sysctl.conf:


# NFS server tuning
sunrpc.tcp_slot_table_entries=128
sunrpc.udp_slot_table_entries=128
vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.swappiness=10

The underlying filesystem choice matters for metadata operations:

  • XFS: Best for large files (recommended for source code repositories)
  • ext4: Good all-rounder with noatime mount option
  • ZFS: Avoid for latency-sensitive workloads due to COW overhead

Complementary IDE settings to reduce NFS operations:


# Eclipse configuration (eclipse.ini)
-Dosgi.locking=none
-Dosgi.bundles.default.startLevel=4

For VS Code, add to settings.json:


{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/**": true
    },
    "files.useExperimentalFileWatcher": true
}

Use these commands to verify performance:


# Server-side NFS stats
nfsstat -o all

# Client latency measurement
time dd if=/mnt/workspace/testfile of=/dev/null bs=4k count=1000

Watch for these warning signs:


# Check for retransmissions (should be near 0)
cat /proc/net/rpc/nfs | grep retrans

# Identify stale file handles
dmesg | grep NFS_

When developers work with IDEs like Eclipse or Visual Studio on NFS-mounted workspaces, even small latency spikes can disrupt workflow. The issue stems from how these IDEs constantly scan and access project files in the background. Traditional NFS configurations optimized for throughput rather than responsiveness often fall short.

# /etc/exports example for low-latency dev environments
/workspaces 192.168.1.0/24(rw,sync,no_wdelay,no_subtree_check,no_root_squash)

The critical parameters here are:

  • sync: Ensures write operations complete before returning
  • no_wdelay: Disables write batching that can add latency
  • no_subtree_check: Reduces server-side verification overhead
# /etc/fstab entry for developer workstations
nfs-server:/workspaces /mnt/workspace nfs rw,hard,intr,noatime,nodiratime,rsize=32768,wsize=32768,vers=3,tcp 0 0

Key client mount options:

  • hard/intr: Prevents hangs while allowing interruption
  • noatime/nodiratime: Eliminates unnecessary metadata updates
  • rsize/wsize: Matches typical IDE file operation patterns
# Add to /etc/sysctl.conf
# Reduce NFS server congestion
sunrpc.tcp_slot_table_entries=64
sunrpc.udp_slot_table_entries=64

# Optimize TCP stack
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_window_scaling=1

For Eclipse, add these VM arguments to reduce filesystem polling:

-Dorg.eclipse.core.internal.preferences.InstancePreferences.usesTransientMode=true
-Dorg.eclipse.core.resources.performAutoRefresh=false

Visual Studio users should disable:

  • File Watcher (Tools > Options > Environment > File Change Detection)
  • Automatic refresh in Solution Explorer

Use these commands to verify latency improvements:

# Measure operation latency
nfsiostat -d 2

# Check RPC call distribution
nfsstat -c

# Network-level monitoring
tcpdump -i eth0 -s0 -w nfs.pcap port 2049

Look for reduced average operation times (especially lookup and readdir) and minimal retransmissions in the NFS stats.