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 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: database management Accept a connection (a syscall). 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) Read a query from a socket (a syscall). Lock a mutex (a syscall). Read/write something to RAM. Read/write something to disk (at least one syscall). Unlock a mutex (a syscall). Write the transaction result to the transaction log (a syscall). 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: _Hey!_medium.com Asynchronous processing with in-memory databases or how to handle one million transactions per…
