← Back to context

Comment by anarazel

4 years ago

Yea, it's not something that's going to stop you dead in your tracks. But it does show up noticeably in profiles. There is stuff that you can do to reduce the pain, like using gigantic pages for the shared memory and remapping your executable's read-only sections, at runtime, so that you're using huge pages for your code. But even after that you can see the cost noticeably.

Right. One of several bits of architectural friction that didn’t matter while your large DBMS was I/O constrained.

  • > Right. One of several bits of architectural friction that didn’t matter while your large DBMS was I/O constrained.

    Yep. Lots of architectural design out there based on IO latency being higher by an order of magnitude or two than now, while memory latency only shrank modestly.

    To be clear, using one process with loads of threads has its own set of issues. Much easier to hit contention in the kernel, e.g. the infamous mmap_sem in linux.