5

Sorry in advance for my lack of familiarity with civi, I'm not the most experienced member of the team.

We seem to be running into a problem with the Rebuild Smart Group Cache job where the cpu will completely max out every time it is run. I looked deeper into the issue in the log and have gotten the following output:

[info] $Fatal Error Details = Array
(
    [callback] => Array
        (
            [0] => CRM_Core_Error
            [1] => exceptionHandler
        )

    [code] => -1
    [message] => DB Error: unknown error
    [mode] => 16
    [debug_info] =>
    DELETE  g
      FROM  civicrm_group_contact_cache g
      WHERE  g.group_id = 120  [nativecode=1213 ** Deadlock found when trying to get lock; try restarting transaction]
    [type] => DB_Error
    [user_info] =>
    DELETE  g
      FROM  civicrm_group_contact_cache g
      WHERE  g.group_id = 120  [nativecode=1213 ** Deadlock found when trying to get lock; try restarting transaction]
    [to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::exceptionHandler prefix="" info="
    DELETE  g
      FROM  civicrm_group_contact_cache g
      WHERE  g.group_id = 120  [nativecode=1213 ** Deadlock found when trying to get lock; try restarting transaction]"]
)

It has also happened on the query

       [user_info] => INSERT IGNORE INTO civicrm_group_contact_cache (contact_id, group_id)
        SELECT DISTINCT id, group_id FROM civicrm_temp_group_contact_cache910
       [nativecode=1213 ** Deadlock found when trying to get lock; try restarting transaction]

Is this at all related to https://civicrm.org/blog/eileen/478-group-contact-cache-deadlocks-improvement ? And would it be alleviated by changing the caching setting mentioned in the blog post?

1

That pretty much sums it up. We have fixed similar problems by changing the Smart Group cache timeout via civicrm/admin/setting/search?reset=1, alongside setting a limit to the Scheduled Job so that only X groups would be considered for each job run.

In another situation we did the following (pasted from our ticket system).

  • set cache clearing to deterministic drush cvapi setting.create smart_group_cache_refresh_mode=deterministic
  • created a scheduled job to run always job.group_cache_flush

Outcome was clearing the civicrm_group_contact_cache after the 5 minute time we allow caches to be valid.

This should resolve deadlocks that occur during cache clearing. It will not resolve deadlocks that may occur during cache rebuilding

Hopefully those give you some ideas of ways to progress

  • What did you set the smart group cache timeout to? – Matt Muchowski Nov 19 '18 at 18:33
0

I have helped out a client with similair deadlock problems and most of the time it turned out that the confifuration of a particilair smart group was causing this.

But finding out which group is causing it is the pain. Sometimes the query causing the deadlock indicates group id. So my suggestion would be try to have a look at group with id 910.

  • I have figured out which group is causing the problem but what should I look for as far as "the configuration of that particular smart group"? – Christia Dec 13 '18 at 2:58

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.