2

This is in planning for upgrade to J!3. I have found no workable solutions here or elsewhere on the web.

CiviCRM 4.6.4
Joomla 2.5.28
MySQL 5.5.38-1~dotdeb.0
Apache 2.2.16
PHP 5.3.29-1~dotdeb.0
Debian Squeeze 6
Linux 2.6.32-5-amd64

On all virtual hosts before I updated CiviCRM (4.4.x and 3.5.x) the Dashboard shows up but the Ajax "Loading..." widget just keeps spinning and freezes the whole GUI. If I click on another CiviCRM link and restart Apache, it will go to that page and I can navigate around but going back to the Dashboard locks it up again. I then updated both instances to 4.6.4 to the same result. I've disabled all other third party extensions to no avail.

I get no unusual errors in Firebug. Under Net, just a bunch of GET 304 reports for a lot of CiviCRM jQuery and other Javascript libraries.

Turning on Debugging with backtrace produces no output. Clean page.

Any help would be greatly appreciated. Thanks in advance.

Improve this question
2

You are experiencing CRM-16035 - Dashlet refresh can crash server.

The default dashboard config is pretty close to maxing out the default Debian config for either Apache or PHP-FPM.

Depending on your server setup (question says just Apache which typically suggests via mod_php) you probably need to increase either the number of connections Apache permits.

You could also remove some dashboard widgets for the affected contact - if the dashboard is currently inaccessible so not editable for you, you could do this by directly editing entries in civicrm_dashboard_contact in the DB.

If you are using Apache + php-fpm or fcgi, you might need to increase the max_children setting in your php-fpm config instead. For non-Apache users, other StackExchange will explain how to increase server limits for your php/webserver configuration.

Improve this answer
2
  • Thanx, Xavier and Chris. I'll do this and let you know but why did this happen all of a sudden on all instances when nothing had changed? I did try to no avail disabling all the dashlets in table civicrm_dashboard. When I am able to get access to the dashlet config page after apache restart only the default Activities dashlet is listed but not active on the dashboard. Still then i get the same issue. – BruceW Jun 18 '15 at 16:31
  • It's hard to say without insight into your situation; perhaps the server is busier, or perhaps you have some recursion in the dashboard configuration. Observing your webserver logs while triggering the issue may help you to understand why your site is particularly affected. – Chris Burgess Jun 18 '15 at 22:16
1

How many dashlets do you have?

The way they are implemented unfortunately triggers 2 http requests (one to get the dashlet, the other behind to generate the content of that dashlet if it's not cached)

So if you have "many", you might end up with more queries that what your server can handle in parallel and slow things, or trigger some protection against denials of services or...

Try increasing the number of php processes that run and see if it fixes things. if it does, you can then remove some dashlets?

Improve this answer
1
  • I've done the DB part and it did clear up the issue on one site but not the other. Next is max_connections. – BruceW Jun 18 '15 at 17:35

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.