back

by stevekemp·12y ago·view on hn ↗
For a hosting company, offering virtual machines, the two most contended resources are CPU & RAM. Disk is practically free, even with SSDs these days.

So it makes sense that they'd want you to pay a premium for more cores, and bundle that with things like storage that you don't want.

1 comments
But NONE of their packages go beyond 8 cores, even with higher priority coming with their higher packages.

I am fine with the fact that I'm sharing cores, I just need more of them.

can you help us understand why you need more cores on a single box and cannot scale horizontally?
I'm using actor-based concurrency extensively, with multiple actors which stay alive between "requests." I don't hold on to cores for a long time, but I hit them extremely often and let them go. It's a pretty intense mix of fibers and threads.

There are always multiple pools of actors always remaining available, and one request might use multiple pools during the course of creating its response.

If I don't have many cores, a lot of time goes into actors waiting for a core to run on. This means a lot of blocking/suspended pauses. With 8 cores of significant priority, certain operations take 2 seconds that would take 11+ seconds with 4 cores, or more with 2 cores. Looking at stacktraces, the majority of that time goes into purely waiting to resume one actor until another completes a task, then looking further, that actor completing a task is just waiting to get onto a core at all. That isn't supposed to be the case. I need to scale vertically, and I'll end up "using" a lot less than if I scaled horizontally.

I need to get away from using a local machine, specifically my actual development "console" if you will, with my IDE etc, because running all my application on this local machine causes the virtual machine on my local hardware to need to schedule out tasks on its threads.

Because of this real need for actual cores, I can also tell when CPUs have true cores, or "hybrid" cores where there are really 4 cores which simulate being 8 cores.

seems to me a refactor to some kind of producer/consumer job queuing is in order? Then you can get N boxes working...