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)

System calls have become more expensive with Meltdown. How to avoid them?

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@denisanikin

RELATED STORIES