Hello,
Same issue I had a few weeks back, deploying a Directus install causes the CPU to hike up. You managed to fix it this time, but I’m assuming a more permanent fix hasn’t been put in place yet?
Thanks,
Tom
The deployment performance itself has nothing to do with Cleavr. The app is build on your own server so depending on how big your app is (and what your app type is - building NodeJS app is heavy for an example but PHP apps don’t need any building except for frontend assets). There isn’t much Cleavr can do, unfortunately and these isn’t because of a Cleavr bug.
There are a couple of measures you could take:
- Upgrading server to have more memory/CPU
- Offloading the built of your app to a different server (needs some manual wiring for this and this is what services such as CircleCI do)
- Enabling GitHub integrations which will build your app on GitHub’s infrastructure (mostly free but has a limit). You might have to do a little bit of work hooking up environment variables.
- Minimizing some unwanted dependencies
To summarize:
- This isn’t inherently a Clever issue
- The app is deployed and built on your own server
- We recommend offloading the build step. GitHub Actions is what we recommend based on how often you have to build it.
1 Like
Hi @ashok -
Interesting response - so my memory/CPU is 2vCPU. This was quickly corrected by a different member of staff previously. It’s also worth noting that another installation of Directus is on the server and that sits around 6%. I understand your logic behind deployments, but why would it stick at 50% after the deployment has finished?
It’s a shame to get push back on this if I’m honest as it was “fixed” previously by another member of your team.
It also creeped it’s way up to 100%.
You have been excellent so far, but I must say this response has disappointed me as I feel “brushed off”. Where as I mentioned in the original post, I have had the issue corrected in the past.
I’m sorry I think there has been some kind of misunderstanding and I’m definitely not pushing it back or brushing it off. I’m just saying what it is and how Cleavr does things - it grabs your code, puts it on your server, builds it on the server itself, and then lets your server run it. Cleavr doesn’t get involved during the runtime of the app. It is normal to have the CPU usage spike during the build as it is a heavy operation. That’s why I suggested to have it move to GitHub Actions (we even provide one-click option for it to get it started)
Once your app is up and running, Cleavr isn’t playing any role. The CPU usage could go up for a number of reasons - the app is a busy/heavy app so it needs a lot of resources, it is contantly trying to do things that it isn’t supposed to do so normally (say trying to load number of images from the upload folder and it is fetching and refetching them for whatever reasons) etc.
I just don’t want to say falsely claim that Cleavr will go and optimize your apps and automagically makes your web apps run faster because it doesn’t. I hope that clears things up a bit more.
PS: If there are things we could do to help you resolve this based on what Cleavr does, we’ll definitely do it and we can even talk over direct messages. Heck, I won’t even mind getting on a Zoom call and trying to figure it out as I love debugging things. But, again, if the performance issue is in the domain of the app itself (or the underlying framework, Directus in this example), there isn’t much I/we could do.
2 Likes
I thing I forgot to mention, one reason why the server could be sitting at some CPU usage because of PM2 trying to constantly restart the app (as for some reason the app is crashing, usually happens if some package is missing or environmet variables missing). You can check the logs and see if that’s happening.
1 Like
Absolutely a misunderstanding, in this case I may have gone ahead and purchased more CPU and the issue not have been corrected. But you have now pointed me in the correct direction. You are absolutely correct, PM2 is trying to constantly restart the app, the reason is an unknown to me.
20:54:02 ⚠️ PUBLIC_URL should be a full URL
20:54:03 🚨 Port 7013 is already in use
2022-02-23T20:54:03: PM2 log: App name:a7qabrordbvbnmla3192.cleaver.rocks id:9 disconnected
2022-02-23T20:54:03: PM2 log: App [a7qabrordbvbnmla3192.cleaver.rocks:9] exited with code [1] via signal [SIGINT]
2022-02-23T20:54:03: PM2 log: App [a7qabrordbvbnmla3192.cleaver.rocks:9] starting in -cluster mode-
2022-02-23T20:54:03: PM2 log: App [a7qabrordbvbnmla3192.cleaver.rocks:9] online
I don’t understand why 7013 port is already in use. It was a random port I assigned and no other app is using it. I’ll change it to something else and see what happens.
Thank you @amiedema - I really appreciate that. I suspect this was the issue that was happening last time. Though @anish figured it out before I did. Could be something to do with Directus?
The port error made me think of a couple of possible issues - it looks like PM2 was trying to start on mult CPUs even though there is only 1, which is why it threw the port in use error and was restarting constantly. We have released some fixes for this over the last month or so and we’ll see if we can repro again to see if there is still an issue or possibly if it’s due to timing around that particular fix.
In any case, I sorted it out on the server. Please take a look at your monitoring and let us know if CPU usage went down.
We apologize for the inconvenience (and confusion)!
Hi @amiedema
Thank you very much for looking into this and it seems the issue is fixed for me.
That’s interesting, I’m paying for vCPU 2 with Digital Ocean:
I provisioned the Cleavr server with one vCPU and upgraded due to issues like this. I wonder if Cleavr doesn’t pick up on those changes?
As for the fix, as @ashok mentioned, this isn’t a bug and is due to the server. How do I correct this myself? I have been following the Directus guide in the documentation so it might be worth updating the documentation to add the step I missed.
Thanks,
Tom
Hey Tom,
I’m glad the CPU usage went down!
We don’t retrieve and update the server specs at this time. If they change after Cleavr provisions, then Cleavr won’t be aware of it. I believe some of the VPS provider APIs have the info available and we do plan on tying that in in the future, it’s just mostly an edge case scenario so haven’t made it a priority.
I checked and I do see 2 CPUs listed when running lscpu command. Well… that does make it even more strange then… I would guess some DO issue or limitation when upgrading the server on DO side. So, what I saw was the apps running stable on one CPU but then the process on the other CPU was restarting constantly (due to port in use). I’d recommend reaching out to DO support to see if they can see an issue with the server after upgrading or if there are known limitations with upgrading where this might be a side effect.