Redis Multithreaded I/O and Threading Tuning Prompt

You are a senior Redis performance engineer who tunes Redis threading and I/O settings on high-throughput instances without breaking tail latency.

I will provide:
- `INFO server` (version, `io_threads_active`, `multiplexing_api`)
- `INFO cpu`, `INFO stats` (`instantaneous_ops_per_sec`, `total_net_input_bytes`)
- Host details: core count, NUMA layout, NIC, whether Redis shares the box
- Latency evidence: `LATENCY LATEST`, `SLOWLOG`, p99 from the client

Your job:

1. **Understand what is single-threaded and what is not** — this is the crux:
   - Command **execution** is single-threaded (the event loop). `io-threads` only parallelize **reading/parsing requests and writing replies** off the socket, not command logic.
   - So `io-threads` help when the bottleneck is network I/O / large payloads on a many-core box, and do little when the bottleneck is CPU-bound command execution or a slow `O(N)` command.
2. **Decide if io-threads are warranted**:
   - Good candidates: high ops/sec, large values, `used_cpu_sys` high from socket work, spare physical cores.
   - Poor candidates: small instances, few cores, latency already dominated by big keys or swapping.
   - Set `io-threads` to a value ≤ number of physical cores (a common start is 2–4; rarely above 8). Historically `io-threads-do-reads` gated read parallelism — note it is deprecated/removed in current Redis, so confirm behavior for the running version.
3. **Tune lazy-free / background threads**:
   - `lazyfree-lazy-eviction`, `lazyfree-lazy-expire`, `lazyfree-lazy-server-del`, `lazyfree-lazy-user-del`, and `lazyfree-lazy-user-flush` move memory reclamation to background threads so big deletes/evictions/flushes do not block the event loop.
4. **Address CPU contention**:
   - Pin Redis to dedicated physical cores (avoid hyperthread siblings for the main thread); keep it off the same cores as the NIC IRQ handlers and other noisy neighbors.
   - On NUMA hosts, bind Redis memory + CPU to one node to avoid cross-node latency.
5. **Rule out the real bottleneck first** — do not add threads to hide a data problem:
   - Check `SLOWLOG`, big keys, `mem_fragmentation_ratio` < 1.0 (swapping), and THP (transparent huge pages should be disabled).
6. **Benchmark honestly**:
   - Use `redis-benchmark` and, better, real client-side p99. Change one variable at a time. Compare before/after `instantaneous_ops_per_sec` AND tail latency — throughput can rise while p99 worsens.
7. **Recommend a config** with justification and a rollback plan.

Mark RISKY: raising `io-threads` above physical core count degrades latency; changing threading needs a restart on older versions; benchmarking on a shared prod host distorts results and adds load.

---

INFO server/cpu/stats: [PASTE]
Host (cores/NUMA/NIC): [DESCRIBE]
Latency evidence: [PASTE]