TIPS Hosting options

[atsak]

Historically I've built Incredible PBX (2025) on Digital ocean droplets. I noticed in some situations there's a race condition and asterisk stops answering calls when the node gets a little busy that it's hosted on and it can't get enough CPU resources. I've moved this to dedicated CPU instances which seems to have fixed it, but it's expensive around $100 a month or something. It's mostly a problem in Toronto and NYC it seems.

In practice, is anyone out there running a slightly busier PBX (ie maybe a hundred or more calls a day) that they're sure isn't refusing calls (carriers tell me there's just no answer to the invite, but it's not a firewall issue, I can see the traffic pass to asterisk but it doesn't answer) and uses a cloud provider? Which ones?

Thanks.

 

[wardmundy]

Never had or heard of a problem with CrownCloud.

 

[atsak]

Never had or heard of a problem with CrownCloud.

Thanks - for this application Atlanta might work , also checking something in Canada maybe Montreal or Toronto.

 

[wardmundy]

Thanks - for this application Atlanta might work , also checking something in Canada maybe Montreal or Toronto.

Atlanta is an awesome site that is right beside the internet backbone. It also happened to be a block from my old office. Let me know if you have any issues. They are great guys to work with. They even host a couple of our older ISOs.

 

[Halea]

You might want to consider a VPS at a data center in Buffalo. Most data centers over there are relatively recent with equally recent hardware and not heavily saturated. Plus it would probably give you better ping times.
That said my approach is to double up the CPU and RAM requirements without going for dedicated CPUs. The extra resource allows to go over the bumps when the actual hardware is too stressed.
Also, are you sure that your PBX is not doing some media conversion ?

 

[atsak]

You might want to consider a VPS at a data center in Buffalo. Most data centers over there are relatively recent with equally recent hardware and not heavily saturated. Plus it would probably give you better ping times.
That said my approach is to double up the CPU and RAM requirements without going for dedicated CPUs. The extra resource allows to go over the bumps when the actual hardware is too stressed.
Also, are you sure that your PBX is not doing some media conversion ?

Yep, looking in Buffalo as well - there's a couple options there. The latency to Atlanta though is sub 50ms so that's fine, I usually have a jitter buffer on for 200ms or so and that's always been OK in terms of voice clarity; the issue is simply not servicing calls as you know.

It's virtually no CPU utilization when the issue exists - I've watched in real time. CPU wait time (or whatever it is called in Linux world) increases rapidly but the actual CPU utilization sits around 1%. I have always used 2vCPU and at least 2GB ram so OK there, since Asterisk is single threaded you can only use 1 but the other takes care of system processes (of which voipbl reloads are intensive).

 

[kenn10]

Keep in mind, looking at CPU utilization on the VM is deceiving if looking at it inside the VM. The host box CPU could be maxed out and your VM could show low activity.

 

[Halea]

... since Asterisk is single threaded you can only use 1 but the other takes care of system processes (of which voipbl reloads are intensive).

Actually even Asterisk benefits from multiple vCPUs as QEMU which is at the foundation of the KVM hypervisor breaks the client thread apart and assigns sub-threads to it. Generally a good portion of these sub-threads can run concurrently.
But based on your description of the issue the VPS seems to be struggling with I/O issues, probably at the storage level, which eventually throw some unhandled or ill-timed exceptions and killing the calls. I never saw this happening on asterisk but I did see it on other legacy software designs (with I/O timed through software loops rather than hardware interrupts).

 

[atsak]

Actually even Asterisk benefits from multiple vCPUs as QEMU which is at the foundation of the KVM hypervisor breaks the client thread apart and assigns sub-threads to it. Generally a good portion of these sub-threads can run concurrently.
But based on your description of the issue the VPS seems to be struggling with I/O issues, probably at the storage level, which eventually throw some unhandled or ill-timed exceptions and killing the calls. I never saw this happening on asterisk but I did see it on other legacy software designs (with I/O timed through software loops rather than hardware interrupts).

ya I don't see any IO wait on the server - just CPU wait. The drives are SSD on the VPS I'm using. It's quite intermittent though - it might happen just a few times over a week and then not again for a few months.