This might be the solution to the huge CPU-spikes. Please read this

FreePBX Tips and Tricks
1

Hi guys,

After a lot of testing, I/we might have found a solution that will fix the huge CPU-spikes every minute. And after a lot of knowledge we are sure that the problem is caused by the commercial-modules and the PHP-zend module. The encryption module php-zend takes a lot of cpu when it is used to run a cronjob. This is a fact, cause I’m not the only one who is saying it. Actually, a lot of prof-developers admit it is using a lot of cpu.

And still FreePBX is running a cronjob every minute, with the php-zend module. The php-zend module is necessary to run nor letting work the commercial-modules. But the problem is; you can’t disable it. You also can’t remove the cronjob, because FreePBX automatically puts the cronjob back.

So, then we have to look at another solution. This is the solution that worked for me:
I’ve tried the system on CentOS 7, and it is giving the cpu-spikes. Then someone said ‘what if we run it on Ubuntu 18? Is Ubuntu 18 nor php 7 still supporting php-zend?’. And that’s what made me curious. What if I can make a fully, dedicated, efficiently, and fast instance of FreePBX 14 at PHP 7 and Ubuntu 18? So, there we go.

It wasn’t pretty difficult with the tutorials down below. The only thing you have to do is changing a deprecated each function. The command for that is standing in the instructions of FreePBX self (click here).

So, it is almost sure, that FreePBX can run on PHP 7 and Ubuntu 18.04. Only problem? They don’t recommend it, so they also won’t give support. But what does it care? It solves the CPU-problem.

This solution did worked for me. I’m not saying this is a permanent solution. I’m just saying this is a solution to solve the problem. Not saying it is a recommended solution to use. Not saying it is a great solution. Just saying that it might work. It did for me.

Extra links to try the installation:
Install FreePBX 14 with PHP 7:
(click here)

BUT! DONT USE THE ASTERISK INSTALL INSTRUCTIONS IN THERE. BUT USE THE DOCUMENTATION FOR ASTERISK 16 DOWN BELOW:
(click here)

When applying the config you will get a “each” syntax error. Just run this command in the command-line:

sed -i 's/ each(/ @each(/' /usr/share/php/Console/Getopt .php

Let me know if this is the real solution.

P.S. I removed the voice-memo cause a lot of people said I was just trolling with them. So, I typed it out. I didn’t removed the thread out myself. First it was hidden, then my account was freezed, and then suddenly Andrew said I could replace the thread with the original one again.

Kind regards,
Serge

1 Like
2

OK so I said this in another thread but it holds true here. If 25 people are reporting a problem some can look at that and say “a lot”, however, when there is a 500K+ user base 25 people is not a lot. It’s all relative.

As well, there seems to be an increase in people using Hyper-V which has it’s own known issues. Take a look at threads regarding Hyper-V there are even different steps to migrate to v14 from lower versions.

I’ll also point out that I helped someone with this exact issue yesterday and it turns out they had their VM configured to share resources. So why they were saying “Oh I have 2 cores for this VM” they really didn’t. They had a VM that could use 2 cores if available and it turns out they could never get the full 2 cores for what they needed. Result was their CPU going through the roof with all the stuff that needs to happen. Once they dedicated the resources to the VM, CPU usage dropped by 90%.

Now as for your solution to this issue. You’re claiming it’s due to commercial modules and their cron jobs. You’re failing to take into account that Time Conditions is not a commercial module and it has a cron job that runs constantly to check the states of the Time Conditions to update them as needed. Not every commercial module runs cron jobs and cron jobs are not related to just commercial modules.

There is also the fact that your solution is going to put people in a position of being unsupported as it’s a manual install on an unofficial OS (Ubuntu/Debian) along with PHP 7 being unsupported right now. While this does take care of the commercial module problem as no commercial modules can be installed on those OSes it doesn’t take the other factors into consideration.

1.) There are still cron jobs that are going to be run with non-commercial modules

2.) People who are having this issue may have commercial modules that they need and thus cannot turn around and go with this options because it breaks all their needs of the PBX.

3.) People having this issue may be on VM hosts that have known issues with FreePBX, like Hyper-V, or this could be cases of people setting up VM guests poorly like the person who had their resources set to be shared and not dedicated on their VM.

This isn’t a overall solution as it only helps those with the ability and the know how to do manual installs and are willing to never use commercial modules or wanting official support for their PBX from Sangoma.

3

Hi Tom,

Thanks for your reaction. I know that this isn’t a overall solution at all.

Then the answers on your other points:

1.) There are still cron jobs that are going to be run with non-commercial modules
Indeed there are still cronjobs. Of course there are. I never said the cronjobs would be completely gone. To be honest, the cronjob is still there. But the cronjob cant do anything with the commercial modules, so they also cant cause a huge CPU-spike.

2.) People who are having this issue may have commercial modules that they need and thus cannot turn around and go with this options because it breaks all their needs of the PBX.
I cant think of that. The commercial modules aren’t really adding special things to FreePBX. Only things you dont really need. Except from the migrate nor upgrade package. But that is my opinion. I can understand that the commercial modules are a great adding to FreePBX.

3.) People having this issue may be on VM hosts that have known issues with FreePBX, like Hyper-V, or this could be cases of people setting up VM guests poorly like the person who had their resources set to be shared and not dedicated on their VM.
My dad and I looked for a solution for over months nor years. We looked at hundreds of things, that could probably cause this problem. Hyper-V wasn’t our problem. It could be for other people.

This isn’t a overall solution as it only helps those with the ability and the know how to do manual installs and are willing to never use commercial modules or wanting official support for their PBX from Sangoma.
Indeed it isn not. But we can come to a great solution, with this next-step and information.

I would like to hear things from people that tried this. Not just someone that hasn’t tried it. However, I do respect your reaction.

Kind regards,
Serge

Lijstitem

4

So basically you’re thought is that a cronjob for a commercial exists when the commercial module doesn’t? That is incorrect. I also pointed out that there are cronjobs that run without commercial modules. So yes there are always cronjobs running that are doing something.

Running a cronjob that can’t do anything means the cronjob is going to run and then timeout. That doesn’t reduce issues that just adds to them because now you would have a bunch of cronjobs running that did nothing but timeout or worse, retried due to the timeout.

You can’t think about the impact commercial modules have? And they don’t do anything special? OK, I get it this is going to be one of those situations.

Again, FreePBX v14 doesn’t have PHP7 support. So are you going to go through v14 modules and make sure that PHP 7 doesn’t screw things up? That all the modules have been checked for the changes between 5.x and 7.x?

So that means when they use your installer that YOU are going to support them? What happens when something like the IVR Module has a bug in it? Are you going to fix that bug and release the update for your installer package? Or will that be left to Sangoma to fix and for the users to do Module Updates like normal?

If you’re going to claim that none needs support from Sangoma or FreePBX for this, then you are supporting right? Or are you just going to include the FreePBX tar.gz file as part of your solution and thus leaving everything up to Sangoma to fix if there are issues? At that point you are still relying on Sangoma support for your whole project.

If you’re plan is to cut out Sangoma from the picture then that means someone has to fill that void. Welcome to the joys of running a FOSS project. Someone still has to support the project.

You can’t have it both ways on this, either you’re cutting Sangoma out completely and making this your own fork or you’re still relying on Sangoma for the maintenance and updates to FreePBX that you just include in your project.

1 Like
5

Hi Tom,

It is not my goal to cut Sangoma off the picture. I’m trying to help people with a problem. A huge problem. I like to give support, but won’t do it permanently. I made this thread to share my solution that might be helpful for others.

I’m just sharing my opinion, and my solution that might help other people. I like to hear criticism about this, but it has to be at the solution itself. Not my goal with it.

So can you please give criticism about the solution itself, or don’t you have one? Cause it is working. Did you try this before reacting? Cause if you did not, then please don’t react anymore.

I would like to hear criticism, bugs, or problems with this solution, but than you really have to try it. Don’t share problems or criticism if you didn’t tried the solution at all.

Kind regards,
Serge

6

Generally a nice post if you want to be 'off the reservation’s for whatever reason and stay strictly open source , as we both do.

Adding a random sleep between 1 and 59 to the various cron jobs if not already thereis helpful to spread the top of the minute rush

If you want UCP, you might also need to fake out the version of libicu-dev(el) that Debian 9 will install because FreePBX is now getting more RH centric and won’t detect a valid library. (There is a recipe here I posted recently.)

1 Like
7

OP deleted posts, but mine was already written so posting…

I’m opting not to listen to the audio recording in order to figure out what the ‘solution’ might be and the language employed herein borders on the trollish to my delicate sensibilities.

Framework versions v14.0.12.4 and v15.0.14 were recently published to mitigate the effects of cron tasks running concurrently.

2 Likes
10

The original poster of this thread deleted his original response and all replies within because (it seemed like) one person disagreed with him.

In the original post the author stated “They (Sangoma) don’t want to give the solution”. I have a gigantic issue with that statement. Simply look at some of the most recent blogs. Especially the one where we posted about performance improvements in several of these “cron jobs”. If you want to be the type of person that ignores that post to then post your own diatribe then that’s up to you. But don’t think that the community that pays attention (like @BlazeStudios) won’t call you out on it.

Additionally Lorne responded with a real Sangoma solution that is on going. However we still don’t see these issues with cpu spikes and the fact that certain people want to continually blame Sangoma is not only draining but it makes developers not want to participate in the project anymore because outside users aren’t even looking at what’s being done. Or the source code. Instead they find it easier to place blame. Well blame is placed. Thanks for that. It’s all Sangomas fault because we won’t “give the solution”

If it were up to me I’d hide this thread. And so I did. Because after the original poster deleted all of his posts it turned to garbage. Unfortunately the original poster accused me of deleting the thread. I don’t know why anyone would want this thread to stay around after all the relevant posts were deleted.

So I’m restoring it to let the community see how awful it is after someone goes through and deletes all of their replies. Threads like this ruin the quality of the community. Not because of what you posted. But because of your massive deletes. That ruins the quality. So I hope everyone enjoys this thread that is barely readable. Maybe it will make you think in the future how awful it is to go around deleting your replies. Not only here but in other threads you participated in.

2 Likes
11

Andrew,

The original poster did not delete his messages, because one person disagreed with him.
You make this up. I contacted him, he had other reasons to delete his post.
So it is not true.

It is nobodies idea to blame someone or Sangoma, do not see it this way.

CPU spikes are visible when using top command and set refresh with ‘d’ to 0.5 seconds.
I do not believe you cannot see this.
Setting a random sleep for every minute cronjob would be a solution.

12

If you look at this thread you’d see it differently. Also there’s no reason for you to be involved in this. You haven’t posted in a while but you come out of the wood work to post on this specific thread and to tel me I’ve made stuff up. It’s very curious.

Did you read Lorne’s reply. Did you read my reply. That’s already being implemented. Additionally running your top command doesn’t produce the output you think it would at least for my team.

Let me reiterate that Sangoma runs a cloud solution that does not require any of the changes you are suggesting.

This thread is complete garbage because the original poster decided it was best to delete everything here and other places he posted. It’s unfortunate that you can’t see that.

13

Andrew,

If you look at this thread you’d see it differently. Also there’s no reason for you to be involved in this. You haven’t posted in a while but you come out of the wood work to post on this specific thread and to tel me I’ve made stuff up. It’s very curious.’

See my posts on cpu spikes, there are many. So not curious, just interested.

Did you read Lorne’s reply. Did you read my reply. That’s already being implemented.

Offcourse I read every reply. Stop blaming me for not reading. It is not true.
Just saying that it was the solution of others like Dicko, but Sangoma implemented it.
It is a working solution. Just saying.

See screenshot for the cpu spikes.

sshot-22
sshot-22957×748 36.4 KB

15

The post from before the last performance blog and before the most recent changes. The post where people called out Sangoma for purposefully not helping. That post? It’s a little out dated now. Don’t you think. I’m tired of reading threads that accuse Sangoma of purposefully not helping. Like your thread. Like this thread.

16

What Lorne answered is probably a solution.
It is released in the edge release. not the stable release yet.
Please don’t react so negative.

17

I asked if you read them. If you read them you’d see where the fix is and I assume you’d go test it out instead of trying to show me here’s a cpu issue which I detailed in the last thread we couldn’t reproduce on Sangomas cloud system that runs 40-60 instances on ONE host.

18

Please don’t accuse and blame Sangoma for not helping other cloud providers for free.

19

I answered that question. I did read them, see my above reaction.

Offcourse I read every reply. Stop blaming me for not reading. It is not true.

20

Reiterating. I didn’t say you didn’t read them. I asked if you read them. You originally replied with “stop blaming me for not reading. It is not true”

21

I am not blaming nor accusing Sangoma. Where are you reading this?
Helping providers for free? Where that came from?

It would just be nice if you would react a little bit more positive.

I will stop now answering on your comments, because I think you have had a bad day and we are not achieving anything here.