Learn Samba - Performance & Monitoring

#Introduction

In episode 8 you met the SMB3 performance parameters; episode 20 is its comprehensive production version: measured tuning and continuous monitoring. Two principles govern this episode: measure first, then tune (tuning without measurement is just guessing — we touched on this in episode 8), and monitoring is an extension of debugging (a problem that isn't monitored is never detected early).

#Advanced Tuning

#Going Deeper on I/O Parameters

Let's continue the large-transfer tuning from episode 8 with full context:

[global]
   aio read size = 16384
   aio write size = 16384
   use sendfile = yes
   min receivefile size = 131072
   write cache size = 262144
   socket options = TCP_NODELAY

• aio read size/aio write size: the threshold (bytes) at which I/O operations become asynchronous — multiple clients don't block each other on large writes.
• min receivefile size: files above the threshold are passed through the kernel zero-copy (splice) — the server CPU is barely touched for large transfers.
• write cache size: per-connection write buffer — helps workloads with many small writes, but RAM consumption rises per connection.
• use sendfile = yes: send data directly from the page cache to the socket.

Why these sizes? The parameters above interact with the filesystem and network. The "right" values depend on your workload — so do A/B benchmarks before and after changing them (episode 8: the dd/fio + iperf3 methodology).

#Kernel and NIC

On the network side, two high-impact improvements:

1. NIC bonding: combine multiple NICs for throughput and redundancy. For Samba, the most suitable mode is 802.3ad (LACP) if the switch supports it — combining two 10GbE cards into one 20GbE link:

sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad,miimon=100"
sudo nmcli connection add type ethernet con-name bond0-p1 ifname eno1 master bond0
sudo nmcli connection up bond0

2. TCP buffers: for high-latency links (large RTT), raise the TCP buffers:

sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

net.ipv4.tcp_rmem/wmem determine the TCP window — for high RTT (VPN, WAN), large buffers increase throughput. Make sure they're persisted in /etc/sysctl.conf if the results are positive.

#Monitoring: smbstatus and Logs

#Real-time Monitoring

smbstatus remains the best daily tool for seeing "what's happening right now":

smbstatus -b | head -30
smbstatus -L

To see trends (not snapshots), record to a file and gather statistics:

*/5 * * * * smbstatus -b | awk '/user/ {print $1, $2}' >> /var/log/samba/active-users.log

#Log Analysis

The logs built in episodes 14-16 give analysis material:

sudo grep -i "NT_STATUS" /var/log/samba/*.log | sort | uniq -c | sort -rn | head
sudo journalctl -u smbd --since today | grep -iE "slow|timeout|denied" | tail -20

uniq -c | sort -rn turns raw logs into an error ranking — you immediately see the most frequent errors, not just the most recent.

#Prometheus Metrics

#node_exporter: Host Metrics

Prometheus needs an exporter. node_exporter provides host metrics (CPU, RAM, disk, network) with minimal setup:

services:
  node-exporter:
    image: prom/node-exporter:latest
    network_mode: host
    restart: unless-stopped

In Prometheus, the target is auto-discovered via SD files (file_sd_configs) or static_config. Metrics relevant to Samba: node_disk_read_bytes_total, node_network_receive_bytes_total, node_filesystem_avail_bytes — all appear without extra configuration.

#Samba-Specific Metrics

For real Samba metrics (session count, active shares), two approaches:

1. A simple custom exporter: run smbstatus periodically, write the output to node_exporter's textfile collector, scraped via node_exporter --collector.textfile:

*/5 * * * * smbstatus -b | awk '/^[0-9]+ / {print "samba_active_sessions " $1}' \
  > /var/lib/node_exporter/textfile_collector/samba.prom

2. A third-party exporter: images like aeriscloud/samba_exporter or similar expose metrics over HTTP — make sure to evaluate them before production use.

#Dashboard and Alerts

With metrics in Prometheus, build a Grafana dashboard with key panels:

• Active sessions (samba_active_sessions) — usage trends.
• Read/write throughput (node_disk_read_bytes_total per interval) — spikes indicate load or an attack.
• Available disk (node_filesystem_avail_bytes) — alert before it fills (relevant for episode 12's snapshot/retention).
• Auth errors (log rate via loki/promtail if you use an observability stack).

Alerts worth setting: disk < 20%, sessions spiking > 2x baseline, rising auth failures, and smbd down.

#Common Pitfalls

• Tuning without a baseline: measure performance before changing — you won't know whether tuning helps or hurts.
• write cache size too large: RAM per connection skyrockets; with 500 connections, a 1 MB cache = 500 MB RAM.
• node_exporter without the textfile collector: Samba metrics aren't built into node_exporter — don't expect unconfigured things to appear on their own.
• Grafana without alerts: a dashboard that doesn't send alerts is a museum, not monitoring.

#Closing

Key takeaways:

• Tuning (aio, sendfile, write cache, socket options) must be measured with A/B benchmarks.
• NIC bonding 802.3ad and large TCP buffers help throughput, especially on high-latency links.
• smbstatus for real-time; log analysis (uniq -c | sort -rn) for patterns.
• Prometheus + node_exporter provides host metrics; the textfile collector brings smbstatus into the metrics.
• Start with 3 key alerts: down, disk full, auth failure spike.

In episode 21 next, we'll cover roadmap & community — the development direction of AD DC and SMB3, the annual SambaXP conference, and the samba.org ecosystem, mailing lists, wiki, and Software Freedom Conservancy. You'll see Samba's future and how to take part in it!