Resources being used up


I have a pretty vanilla installation of SuiteCRM with the Joomla customer portal installed.

It seems more often now than before, but resource limits keep getting reached on my server. Specifically, Entry Processes, CPU Usage, and Memory (both virtual and physical).

After looking at what is running, it’s all the index.php file in SuiteCRM.

I don’t have a lot of users that use it. Currently there are about 15 active users. The database has a few thousand entries in it (mostly leads), and it is running on a shared server (it’s our server, so I can manipulate it a bit).

I’m wondering if anyone has had similar issues and if you could possibly let me know what to look at. I’m assuming the processes are likely just running longer than they should be. I’m wondering if there are any database optimization tips someone could maybe give me, or some areas to improve performance.

Thanks for the help.


My colleague Jim provides some performance tweaks in his book SuiteCRM For Developers, which is available here and a very good resource for any Suite developers.

I’ve copied the relevant pages here in case they help you


Installing a PHP opcode cache will increase the performance of all PHP files. These work by caching

the compilation of PHP files resulting in less work on each request. Furthermore SuiteCRM will use

the caching API of some PHP accelerators which will further increase performance. If you are using

Linux then APC is the usual choice. Windows users should check out WinCache2.


MySQL is notorious for having small default settings. Fully optimising MySQL is outside the scope

of this book (however checkout for a helpful Perl script which will provide setting

recommendations - note that you should be careful when running files from an unknown source).

One small change that can make a big difference is increasing the innodb_buffer_pool_size.

If you have migrated or imported a significant amount of data it is possible that some tables will be

fragmented. Running OPTIMIZE TABLE tablename can increase performance.


Adding indexes on the fields of modules can improve database performance. The core modules

usually have important fields indexed. However if you have created a new module or added new,

often searched fields to a module then these fields may benefit from being indexed.

Config Changes

The following are some config settings that can be used to improve performance. These settings should be set in the config_override.php file. See the chapter on the Config files for

more information.

$sugar_config[‘developerMode’] = false;

Unless you are actively developing on an instance developerMode should be off. Otherwise each

page request will cause cached files to be reloaded.

$sugar_config[‘disable_count_query’] = true;

For systems with large amounts of data the count queries on subpanels used for the pagination

controls can become slow thereby causing the page to be sluggish or outright slow to load. Disabling

these queries can improve performance dramatically on some pages.

$sugar_config[‘disable_vcr’] = true;

By default opening the detail view of a record from the list view will also load the other records in

the list to allow for easy moving through records. If you do not use this feature, or, if loading the

detail view for some records has become slow, you can disable this feature.

$sugar_config[‘list_max_entries_per_page’] = ‘10’;

The number of records shown in each page of the list view can be decreased. This will result in a

slight increase in performance on list view pages.

$sugar_config[‘logger’][‘level’] = ‘fatal’;

Lowering the log level means that there will be less log messages to write to disk on each request.

This will slightly (very slightly) increase performance.

Thanks for the resources!

I’ll probably buy that book.

I found that the issue was relating to an error that I didn’t check (doh). It was a logic hook issue. More specifically, I found this error:

Unable to load custom logic file: include/SugarSearchEngine/SugarSearchEngineQueueManager.php

I found the solution here

I backed up and removed the /custom/Extension/application/Ext/LogicHooks/SugarFTSHooks.php file and everything is working fine now.

I’ll get that book. Thanks for pointing me to it.

Thanks for posting back with your solution. Hopefully that might help anyone else with the same issue that see this.

You’re welcome.

The issue seems to be minimized now. I did do a lot of the performance tweaking that I could. Every morning the resources end up being used up, and it’s always in the morning. It isn’t the first time the system is used in the morning, but it’s soon after. The afternoon is actually the busier time for usage, so it isn’t a load issue from what I can tell.

Do you know if there are any hooks or scripts that run (outside of cron) when someone uses the system on a regular basis? For example, WordPress often performs small updates when someone simply visits the site running it. Is there anything that runs something when a user connects to SuiteCRM that could be causing an issue?

I haven’t been able to narrow this down to a specific task causing the issue. We generally use Cases, Leads, Calls, and Notes–with some small usage of other modules. I don’t have the ajax detail update enabled.

Essentially, from what I can tell, something is causing a bunch of index.php processes to run. Due to this, resources are used up on my account–it’s a shared server. I get all users to log out and I still have issues with it–processes keep getting created and using up all resources. The tracking database doesn’t indicate that anything is being saved or changed anywhere. I end all of the PHP processes, and it still continues to create more and more processes. This goes on for about half an hour, then everything works fine until the next morning.

Also, the system does not have issues on the weekends when it isn’t being used.

I have a lot of what was going on around the time that this started. The logs really don’t indicate exactly what was happening. I have developer mode on and the logs set to debug. The logs seem to be just regular logs, no errors around the time of the outage. Just some info and debug logs that seem quite normal. Query Execution times also seem pretty good overall – slowest I could fine was this one----Query Execution Time:0.028795003890991

I did notice that Hook called: ::server_round_trip was called near the time of the issues coming up. That’s the only thing that I can see that maybe would load something that causes this to happen. I’m just not sure where to go from here.

Any ideas would be greatly appreciate.

If you go to Admin then click Scheduler you should see how often and when Suite runs all it’s tasks. Maybe have a look there and see if any of the times coincide with the times you are having issues. You can edit these settings though they may affect how well Suite runs

The server_round_trip hook is called at the end of a page request. It’s called from the sugar_cleanup function, which I think has the knock on effect of meaning it can be called from cron jobs.

Do you have many workflows set up?

I don’t have cron running at the moment, so none of those schedulers have run since the 15th.

I don’t have any workflows set up. I did have a workflow that was causing some issues, but I deleted that. Maybe there is something still trying to do something in that old workflow? Do you know how I might check that? I didn’t think Workflows ran at all if cron isn’t set up to run.

If you don’t have cron running then it wont be the workflow that’s causing issues.

Sorry, but I’m running out of things to suggest.

This is such a big problem for me right now. I have a SuiteCRM instance on a VPS and 5 active users.

Every now and then a there is a rapid increase in TCP connections to CRM from our IP address. So it probably
is client related. Most of them FIN_WAIT2. They spawn at a rate of 2 a second or so. And hog php and mysql process.

I am getting kinda desperate here. Although I do have process monitoring and restarting setup. Memory often runs
out before it can restart it. CRM services outages due to bugs are becoming a major annoyance to users.

I wish I could give you some more advice. We moved to using SalesBox instead due to these issues. It also takes the development side of things off of my plate, which is nice.