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)](https://en.wikipedia.org/wiki/Meltdown_%28security_vulnerability%29) 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/](https://www.theregister.co.uk/2018/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](https://hackernoon.com/tagged/database) [management](https://hackernoon.com/tagged/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: [**Asynchronous processing with in-memory databases or how to handle one million transactions per…** _Hey!_medium.com](https://medium.com/@denisanikin/asynchronous-processing-with-in-memory-databases-or-how-to-handle-one-million-transactions-per-36a4c01fc4e4 "https://medium.com/@denisanikin/asynchronous-processing-with-in-memory-databases-or-how-to-handle-one-million-transactions-per-36a4c01fc4e4")[](https://medium.com/@denisanikin/asynchronous-processing-with-in-memory-databases-or-how-to-handle-one-million-transactions-per-36a4c01fc4e4)