4 ms·
Yes. And we all know how well EBS works for consistent database performance. That's why I said "... would rule out running databases in containers ..."
by pilif 13y ago
Yes. And we all know how well EBS works for consistent database performance. That's why I said "... would rule out running databases in containers ..."
- vidarh 13y agoThat is entirely irrelevant - it's an implementation detail of AWS. The volume could just as well be bind-mounted from the same local host.
- pilif 13y agoThat's what I was asking in my first question: Do you get access to a raw device node of the host OS?
- yebyen 13y agoNo, I don't think so. This is prevented by kernel namespaces and default privileges of LXC in Docker. That doesn't mean you can't bind mount a directory from your host into your container though; there's also the concept of volumes.
- vidarh 13y agoI don't think so, but bind-mounts makes that irrelevant for most uses. If you need bare-metal device access, then you have very specialised needs that apply to a very tiny fringe set of users (as an example, we can reach 1GB/s reads from our SSD RAID arrays on some of our containerised database servers without resorting to raw device access).
- ajays 13y agoIs it GB/s or Gb/s ? Even SATA3 maxes out at 6Gb/s
- jpetazzo 13y agoI don't know if they meant GB or Gb, but for the record, I didn't see any difference in disk performance between native and containerized apps. In that case, that was pulling ~900 MB/s seq reads from a RAID10 disk array of 8 old 7k HDD. This is not surprising, as the code path for block I/O is exactly the same for native and containerized processes.