Blocking I/O design Blocking I/O model

Cause ID sk-blocking-io · Primary owner Game team (Server development)

Open the interactive card with figures and simulations →

In a design where a thread can’t do anything else while it waits on one socket, everything slows down as the player count grows.

Why Each connection waits on its own reads and writes → Effect A delay on one connection spreads to the other connections on the same thread → On screen As concurrent users grow, everyone gets slow motion and input lag

Symptoms: Slow motion, Input lag
Factors: Stall
Who’s affected: Whole server
When: When crowds gather, Evening peak hours
Owner: Primary owner Game team (Server development)
Game team action items: Move to asynchronous I/O based on epoll, IOCP, or io_uring.
On the graph: Rises with load · Response time, thread count
Where to look: Game server thread count and per-thread voluntary context switches (cswch/s, times a thread stopped to wait for a resource) from pidstat -w -t, compared with response time as concurrent users grow
Confirmed if: Response time climbs steeply as concurrent users grow, and most of the threads (one per connection) show many voluntary switches while barely using CPU (waiting on sockets)
Ruled out if: Threads use CPU continuously without waiting: compute overload (“Tick overrun”)
Check with: Infra tools (no game code needed)

Sources

epoll(7) — Linux manual page Linux man-pages
I/O event notification that scales to watching many fds at once
I/O Completion Ports Microsoft
The Windows approach of handling many asynchronous I/Os with a pre-created thread pool
pidstat(1) — Linux manual page sysstat
cswch/s in -w: voluntary context switches where the task stopped on its own to wait for a resource; -t shows them per thread

Blocking I/O design Blocking I/O model

Sources

See also

Same layer: L8 Sockets and protocols

Same symptom (Slow motion), other layers