Performance tuning
Throughput and latency in LeilFS are shaped at three points: the client (caching and readahead), the chunkserver (concurrency, readahead and disk headroom), and the network topology (where replicas live relative to readers). Tune the layer that matches your bottleneck and measure before and after each change.
Client-side tuning
Client behaviour is set with leil-mount -o options (see the full list in Mount options).
| Option | Guidance |
|---|---|
sfswritecachesize | Increase for write‑heavy workloads (e.g. 512 or 1024 MiB; range 16–2048, default 128). |
readaheadmaxwindowsize | Increase for large sequential reads (per‑descriptor readahead in KiB, default 16384). |
sfscachemode=NO | Disable client caching for shared‑write workloads where several clients write the same files, to keep them consistent. |
sfsentrycacheto | Raise to cut master load on directory‑heavy workloads (directory‑entry cache timeout in seconds). |
sudo leil-mount /mnt/client -H 192.168.10.10 \
-o sfswritecachesize=1024,readaheadmaxwindowsize=32768
Per‑path overrides exist too: the nodatacache and noattrcache extended attributes turn caching off for specific paths without changing the whole mount.
Chunkserver tuning
Set these in leil-chunkserver.cfg and reload the service.
| Setting | Guidance | Default |
|---|---|---|
NR_OF_NETWORK_WORKERS | Increase for high client concurrency (e.g. 8–16 on busy nodes). | 4 |
READ_AHEAD_KB | Enable for sequential read patterns (e.g. 4096). Uses posix_fadvise prefetching. | 0 |
| Metadata/data separation | Put chunk metadata on NVMe using the leil-hdd.cfg pipe (split) syntax — see Storage device setup. | — |
HDD_LEAVE_SPACE_DEFAULT | Free‑space threshold at which a disk is treated as full. Lower if disks fill too early, but keep meaningful headroom. | 4GiB |
Network topology
Reads prefer the nearest replica, so telling the master which chunkservers share a rack or failure domain improves both availability and read performance. This is configured in leil-topology.cfg — the concept, address formats and switch‑distance model are covered in Network setup.
For tuning, the goal is simply to ensure every reader has a replica close by and that replicas are spread across failure domains. Combine topology with goal/label placement (see Replication) so chunks land where both durability and locality are satisfied.
If the cluster runs with TLS, expect extra CPU cost per connection. Account for it when sizing chunkserver workers and client counts.