0

I have a new Magento 2.3.3 install that is causing me various problems and I'd really appreciate it if someone could point me to a set of things to check to ensure its integrity that may help point me to a solution. I figure its a post installation step I've missed and particularly think its a Cron issue as its quite strange. I have this new install running on an AWS architecture, the server is a t3a.medium Ubuntu machine with 4GB's of RAM, I've set PHP to 3GB and all .htaccess files to 3GB also. I've linked this DB to a RDS MySQL server thats running the database, its a small DB server. Once the installation was completed and I was happy all seemed to be running fine I created an AWS AMI, machine image. I could view the site and enter the admin system and start configuring stuff, so all seemed good.

However, when I started to try and expand functionality by installing extensions problems showed up. The first issue involved 2 extensions which where the Stripe payments system and DragDropr, although I don't think the problem has anything to do with the extensions themselves. Installation of the extensions fails with a Rollback message from the admin interface. Checking logs says that PHP had a memory allocation blow-out even though I've set everything to 3GB. Then the server goes stupidly slow and starts hanging and when I do a 'top -c' in the terminal it clearly shows that my cron setup must be wrong or is somehow getting stuck as there seem to be stalled Magento cron jobs stuck at the top of the list.

Anyway, when this happens I terminate the server and restart a fresh one from the AMI and everything is back running. As another example, the weird thing is, and it just happened, I logged into a fresh AMI that i started a couple of weeks ago and have not worked on or touched since. I went to the web-setup panel to try and upgrade to 2.3.4 and the Readiness check fails the 'Checking Component dependency' stage.

I decided to terminate that server, start a new one from the same AMI and hey presto it passes the 'Checking Component dependency' stage. The only difference between the 2 servers was the failed 1 has been running untouched by anyone for a couple of weeks. The only changes on it, I reckon, will be through automated elements that are running on the server, i.e. the cron stuff probably.

Sorry for the long winded detail but I can't get past what I could have set wrong and how Magento's Cron systems work to link the various system elements, DB, file structure, etc. that could be causing the issues. I've been very diligent, I thought, making sure settings and permissions are all correct but I do reckon my Cron set-up is related. I'm also not sure if having the DB off server on RDS could be an issue, although it doesn't seem to be for any other system interaction.

  • Consider posting your top or htop report so we can get a glimpse into your 4GB server that you have give 3G to PHP. Where do you think MySQL is going to run? – Wilson Hauck Feb 7 at 21:52
0

Looks like you have few issues there.

First you can try to fix component dependency issue, if you don't see anything in server logs and Magento logs, follow last of this article:

https://devdocs.magento.com/guides/v2.3/comp-mgr/trouble/cman/component-depend.html

PHP memory, you need adjust this on your user.ini and check in phpinfo, also PHP cli memory should be checked. If this dosen't help:

https://httpd.apache.org/docs/2.4/misc/perf-tuning.html

Cron schedule

Check tabel is there a lot pending jobs? Search in Google (you can truncate this tabel) Plus adjust settings for Cron on backend, Cron scheduler lifetime.

You can also monitor memory usage via cloud watch. Check do you hit swap.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.