51–60 of 72 posts
Earlier quoted context omitted.
And deploy it...where? AWS, Azure, GCP and virtually all other providers have first class Docker and Kubernetes support. You can barely even host a Solaris VM anywhere today.
That would by Joyent [0] the makers of SmartOS (Basically, Open Source Solaris). Their Triton cloud product uses SmartOS under the hood. [0] - https://www.joyent.com/smartos
on osx, i know for a fact Docker for OSX is pretty darn slow due to its way they handle filesystem. but using Dinghy greatly helped sped everything up due to it using nfs. just in case anyone wanted to know.
Earlier quoted context omitted.
Hmm. I'm definitely not an expert in hypervisor implementations but I would guess that it should not proxy any calls to the host kernel...
But as fadvise can reliably only be implemented in the host kernel, the one in hypervisor is basically a noop.
Earlier quoted context omitted.
If your VM call to `fadvise` is not calling the underlying host kernel operation, is it even working?
VM certainly does "call underlying host kernel operation", it just does so indirectly — the guest userspace calls fadvise(), kernel implementation of fadvise() asks the virtio disk driver to perform particular read/writes, the virtio driver asks underlying kernel disk driver to read/write individual disk sectors (without knowing, that they are related to specific file in guest filesystem). This specific bug was cause…
I asked the engineer in question to investigate, but after looking he said, "It's nothing I could be doing."
So I sat with him and used git-bisect to prove to him it was his commit: he had added trace logging within a couple of tight loops in the hottest parts of the code base. I smiled.
"But it's trace. That's disabled in production. It can't be that," he said. But we had already proven it was that commit, and the only thing that changed was additional logging.
Long story short, the logging library was filtering calls by level just before actually writing, rather than as close as possible to the call site—a design bug, for sure.
I had him swap out the library everywhere it was being used.
Moral: logging is not free.
One time we observed a dramatic drop-off in performance from one of our services after a certain day that week. I looked at recent releases and saw it perfectly coincided with one. I asked the engineer in question to investigate, but after looking he said, "It's nothing I could be doing." So I sat with him and used git-bisect to prove to him it was his commit: he had added trace logging within a couple of tight loops…
It's not easy problem to solve. The best I've come up with so far, is using a decorator in conjunction with a DI framework that supports it. It's still only a wrap around method calls, but it enables completely turning off logging in production, and enable it when it is needed without making a special build, or wasting resources during normal execution.
This is not the original title. The original title is "Another reason why your Docker containers may be slow".
Earlier quoted context omitted.
And deploy it...where? AWS, Azure, GCP and virtually all other providers have first class Docker and Kubernetes support. You can barely even host a Solaris VM anywhere today.
That would by Joyent [0] the makers of SmartOS (Basically, Open Source Solaris). Their Triton cloud product uses SmartOS under the hood. [0] - https://www.joyent.com/smartos