3 ms·

Database servers do much better with 4 cores than 4 VMs. In fact they do even better without any VMs at all.

by eloff 11y ago

derefr 11y ago
I knew someone would argue this point but I couldn't figure out how to correct the original post to be clearer. "Virtual machine" has come to refer to a specific isolation and security model through, effectively, having a microkernel (the hypervisor) with hardware-accelerated microkernel RPC (hypercalls). But the abstract concept of a virtual machine doesn't require that isolation; it just requires partitioning of resources so that you can treat each partition as its own independent virtual Von Neumann machine. A DB that pins each of its worker threads to a separate core, has a set amount of non-pageable memory reserved for each thread (and perhaps does SR-IOV to get network frames directly to the right thread) is effectively, in resource allocation terms, four independent virtual Von Neumann machines. Each pinned thread sees no context switches, gets no cache incoherency, suffers no NUMA-based latencies, etc. You've got four little machines, each with their own uncontested memory-bus and network bandwidth, that just happen to share die space (and thus have a cheap IPC fabric between them.) I mean, you get 90% of what having a modern hypervisor-managed VM gives you just by using processes in the first place (as opposed to the old "single shared address space" model of the Apple II and IBM PC, where things like TSRs made sense.) But in the decades since the invention of the "process" concept, we've gone past the original conception of a "process" as its own virtual machine, and optimized for multi-user, heavily-multiprocessing time-sharing workloads where context switches are frequent, memory bandwidth is shared, IO hardware is shared (and thus has its access linearized through the kernel), etc. We've realized that most people don't need to be allocated a circuit, so scheduling packets will do; that most people don't need memory reservations, so an OOM killer will do; that most people don't write hard real-time software, so context switching will do; etc. (And we've even given up on the address-space isolation, with threads and other shared-memory IPCisms.) Most of what we use hypervisor-managed VM setups for today is simply to enforce the resource partitioning that Operating Systems gave up on, so that we can have "processes" that actually do give us resource guarantees. If you're an ops person and you don't know what workload you're going to be running but want that enforcement there anyway, hypervisor-based VM management makes perfect sense. On the other hand, if you as the developer get to design your entire "embedded system" or "appliance" or "service" of OS+app yourself, you can throw out the hypervisor and get your VM model from the OS itself, by teaching your app to tweak the OS in all sorts of places ala Snabb Switch. Either way, the goal is to partition your machine into several smaller independent ones that never have to wait in a queue behind one-another. You can get that from an OS, or from a hypervisor; but what you get is virtual Von Neumann machines either way.
- gpderetta 11y ago
  Not all parallelisable jobs can be profitably statically partitioned in independent threads or processes. Many (i.e. anything that is not embarrassingly parallel) require dynamic scheduling and load balancing, which is easier and faster to do on a single address space.
  - derefr 11y ago
    I did hedge in the original comment with a "not much you can do that's faster" rather than a "nothing you can do faster." I write control-plane software in Erlang; I am well-aware of software that can take advantage of a 12- or 36- or 100-core CPU. :) But, most software that people "parallelize" with pthreads is not that type of software, and would be much better served being split into independently-partitioned shared-nothing worker processes, ala Redis. Not only for performance sake, but also because that frees you from the operational constraint of needing a single big machine to run it on. (You still can run all your shared-nothing worker processes on the same piece of Big Iron, but you don't have to, and that flexibility is important for designing a solution in the face of unknown usage profiles.)
- eloff 11y ago
  Differences between VMs and theoretical virtual constructs asside, with most databases you don't have a shared-nothing architecture. If you do then it doesn't make much difference whether you're on a 4-core VM or 4 1-core VMs. But the common case, for relational databases anyway, is all the data in one big memory space shared by all threads. That would be seriously hobbled by having to do IPC instead of just sharing the memory.

Database servers do much better with 4 cores than 4 VMs. In fact they do even better without any VMs at all.

by eloff 11y ago

Database servers do much better with 4 cores than 4 VMs. In fact they do even better without any VMs at all.

I knew someone would argue this point but I couldn't figure out how to correct the original post to be clearer. "Virtual machine" has come to refer to a specific isolation and security model through, effectively, having a microkernel (the hypervisor) with hardware-accelerated microkernel RPC (hypercalls). But the abstract concept of a virtual machine doesn't require that isolation; it just requires partitioning of resources so that you can treat each partition as its own independent virtual Von Neumann machine. A DB that pins each of its worker threads to a separate core, has a set amount of non-pageable memory reserved for each thread (and perhaps does SR-IOV to get network frames directly to the right thread) is effectively, in resource allocation terms, four independent virtual Von Neumann machines. Each pinned thread sees no context switches, gets no cache incoherency, suffers no NUMA-based latencies, etc. You've got four little machines, each with their own uncontested memory-bus and network bandwidth, that just happen to share die space (and thus have a cheap IPC fabric between them.) I mean, you get 90% of what having a modern hypervisor-managed VM gives you just by using processes in the first place (as opposed to the old "single shared address space" model of the Apple II and IBM PC, where things like TSRs made sense.) But in the decades since the invention of the "process" concept, we've gone past the original conception of a "process" as its own virtual machine, and optimized for multi-user, heavily-multiprocessing time-sharing workloads where context switches are frequent, memory bandwidth is shared, IO hardware is shared (and thus has its access linearized through the kernel), etc. We've realized that most people don't need to be allocated a circuit, so scheduling packets will do; that most people don't need memory reservations, so an OOM killer will do; that most people don't write hard real-time software, so context switching will do; etc. (And we've even given up on the address-space isolation, with threads and other shared-memory IPCisms.) Most of what we use hypervisor-managed VM setups for today is simply to enforce the resource partitioning that Operating Systems gave up on, so that we can have "processes" that actually do give us resource guarantees. If you're an ops person and you don't know what workload you're going to be running but want that enforcement there anyway, hypervisor-based VM management makes perfect sense. On the other hand, if you as the developer get to design your entire "embedded system" or "appliance" or "service" of OS+app yourself, you can throw out the hypervisor and get your VM model from the OS itself, by teaching your app to tweak the OS in all sorts of places ala Snabb Switch. Either way, the goal is to partition your machine into several smaller independent ones that never have to wait in a queue behind one-another. You can get that from an OS, or from a hypervisor; but what you get is virtual Von Neumann machines either way.

gpderetta 11y ago
Not all parallelisable jobs can be profitably statically partitioned in independent threads or processes. Many (i.e. anything that is not embarrassingly parallel) require dynamic scheduling and load balancing, which is easier and faster to do on a single address space.
- derefr 11y ago
  I did hedge in the original comment with a "not much you can do that's faster" rather than a "nothing you can do faster." I write control-plane software in Erlang; I am well-aware of software that can take advantage of a 12- or 36- or 100-core CPU. :) But, most software that people "parallelize" with pthreads is not that type of software, and would be much better served being split into independently-partitioned shared-nothing worker processes, ala Redis. Not only for performance sake, but also because that frees you from the operational constraint of needing a single big machine to run it on. (You still can run all your shared-nothing worker processes on the same piece of Big Iron, but you don't have to, and that flexibility is important for designing a solution in the face of unknown usage profiles.)
eloff 11y ago
Differences between VMs and theoretical virtual constructs asside, with most databases you don't have a shared-nothing architecture. If you do then it doesn't make much difference whether you're on a 4-core VM or 4 1-core VMs. But the common case, for relational databases anyway, is all the data in one big memory space shared by all threads. That would be seriously hobbled by having to do IPC instead of just sharing the memory.