Hello @eduardobaer Please provide as much informationn as you can.
How many contacts? Mautic Version? OS? HTTP server, DB engine, caching…
Please also check this post to make sure your current hardware is more or less on par with that:
Sounds like this is your issue.
@eduardobaer If you already made sure you’re not short on resources, you might also want to make sure you use DB to store sessions and also enable memcached.
I’ve also experienced slowness with a similarly sized db. I’ve gotten some improvement by increasing available RAM but it’s still more sluggish than I’d like.
I believe I have a clue as to what’s causing it. Anytime I SSH into the server and run htop, I see 4 long-running php-fpm threads. These threads run for hours and once they complete, they seem to start up again pretty quickly. I have a pretty standard implementation with few plugins, so I’m pretty sure there are some bugs in Mautic that cause these long-running processes to loop forever and eat up considerable resources. Do you see that on your server as well? Anyone have any ideas on how to find out what these threads are running?
Could you share your cron jobs? @gabe
The database and memcache have the same locking mechanisms as disk based session handling.
Just a follow up in case it is helpful to other people.
Thanks a lot for everyone’s help. It seems that the issue is now fixed for me (hopefully it will stay like this). I am not 100% sure on what solved it but here are the things I’ve done:
a) Installed OPCache
b) Installed Memcached and set session lock to OFF
c) Removed a couple of dashboard widgets from the initial page
I am not 100% sure the issue is solved and wont come back, but the speed is now SO MUCH better that it feels like it is a completely different product.
Thanks a lot for everyone’s help
Best,
eduardo
Glad to hear it @eduardobaer, well, steps a and b are crucial for a fast running installation once you start having many contacts.
Indeed dashboard widgets can take a lot of resources, but only whenever you run the dashboard page. But the dashboard also benefits A LOT from the caching you just installed, so maybe you can try to enable those widgets again and see if there’s any difference now.
On top of that, one trick is to change the default Mautic page to something else, like the calendar or campaigns.
Would you please mark my response as the solution? thank you!
Sure, here it is:
0,15,30,45 * * * * php /var/www/html/app/console mautic:segments:update
5,20,35,50 * * * * php /var/www/html/app/console mautic:campaigns:rebuild
0,5,10,15,20,25,30,35,40,45,50,55 * * * * php /var/www/html/app/console mautic:campaigns:trigger
0 1 * * * php /var/www/html/app/console mautic:iplookup:download
12,27,42,57 * * * * php /var/www/html/app/console mautic:import
55 4 1 * * php /var/www/html/app/console mautic:maintenance:cleanup --days-old=730 --no-interaction
I’m certain, however, that these are not the cause of the long-running processes because I can manually run them and they all complete quickly. Also, php-fpm is only loaded when there is a webserver hit, not from CLI or cron. I’m thinking the long-running processes are from web-site visitors and associated tracking/forms. Any idea how to troubleshoot this?
Yes, that was the idea @gabe, some of the tasks those cron jobs start have a lock, hence it is normal that they run for a long while and once they finish they get just launched again, but if you are certain those complete fast, there’s no reason to think so anymore.
Definitely search all logs for any errors, specially NginX and fpm logs, also make sure both have enough resources, do revise your fpm config.
If that doesn’t solve your issue you might want to start digging specific processes with ps, for example:
ps -e --forest to see how processes relate to each other or ps -eo comm,etime,user | grep httpd to check the execution time of a process, all in order to isolate the culprit and dig even more.