Surely you’ve heard of Meltdown by now. It’s a hardware vulnerability that allows an unauthorized process access to privileged memory. It affects Intel processors produced since 1995. Here are some details: https://en.wikipedia.org/…/Meltdown_(security_vulnerability)

The only known effective way to fix this issue is to apply a patch to the kernel of your OS (Linux, Windows, macOS), which will significantly increase the cost of system calls: that will result in an average of 5–30% of performance penalty on everything you run on your Linux, Windows, or macOS. More details here: https://www.theregister.co.uk/…/01/02/intel_cpu_design_flaw/

What does that mean for the software you use? The more syscalls it makes per operation the worse. That is especially bad for database management systems (DBMS), because they normally make a lot of syscalls per query. This is a very simplified execution chain of a traditional relational DBMS processing a transaction:

1. Accept a connection (a syscall).
2. Create a process or a thread (a syscall), or (if a database uses a pool of pre-created threads) find a free thread in a thread pool (which means accessing a shared variable that stores the states of threads which should lock and unlock, resulting in two syscalls)
3. Read a query from a socket (a syscall).
4. Lock a mutex (a syscall).
5. Read/write something to RAM.
6. Read/write something to disk (at least one syscall).
7. Unlock a mutex (a syscall).
8. Write the transaction result to the transaction log (a syscall).
9. Write a response to the socket (a syscall).

Many traditional DBMSs (MySQL, Postgres, Oracle, etc.) make quite a few syscalls per transaction. They could get significantly slower on a patched OS, where syscalls have become more expensive.

Fortunately, there are some modern DBMSs, such as Redis, Aerospike, or Tarantool, that are targeted towards the performance of 100K+ transactions per second per CPU core, and they adopt a lot of smart tricks to reduce the number of syscalls per transaction.

One such trick is using a single socket for many queries executed in parallel, which allows reading a number of parallel queries at once, persisting them to the transaction log at once, and writing all the responses to a socket at once. Less syscalls — more useful work.

See details here: