http://gyazo.com/6e3b2f39362a1b4378a9d5b86d8f208a

Was deleting two spam comments and both errored out. One comment got deleted, one didn't.

#1890470: views_content_cache_update_set is vulnerable to deadlocks/slow lock releasing when a lot of content being inserted (innodb)

The deadlock happens in a write intensive environment. I ended up not using views_content_cache due to those issues (and some other issues) if I recall correctly.

Comments

nnewton’s picture

Ya, I'm going to have to open an issue with the module. It really isn't setup correctly at all. It is a nice module, but close to not usable in high performance environments because of this, which is somewhat amusing considering its purpose.

hefox’s picture

The issue in views content cache has been patched and a new alpha release pushed.

On the codebase I was using it for, I through it out and did my own caching using wildcard clearing. e.g. cache for view blogs with cid blog_xx, update a blog call cache_clear_all('blog_*', 'cache_views_data', TRUE). If simple enough clearing roles, works nicely.

tvn’s picture

Priority: Normal » Major
Issue tags: +Drupal.org 7.1

The latest alpha3 release is on D.o now, but it didn't help with the massive deadlocks a few days ago. Tagging and bumping priority, we still need to do something about this module.

tvn’s picture

It seems we had no troubles with this one lately. Is this still an issue? Should be downgrade priority / postpone it?

tvn’s picture

Issue tags: -Drupal.org 7.1

There were no problems with this recently. Query killer might be mitigating this though. Untagging from immediate D7 upgrade follow ups. Infrastructure team will deal with this if/when the problem appears again.

Project: Drupal.org infrastructure » Drupal.org customizations
Component: Drupal.org module » Miscellaneous
sebaz’s picture

It looks like the problem is still happening on sites with this module: views_content_cache

LATEST DETECTED DEADLOCK
------------------------
151013 10:47:49
*** (1) TRANSACTION:
TRANSACTION 5701C073, ACTIVE 3 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 485 lock struct(s), heap size 63928, 403 row lock(s), undo log entries 141
MySQL thread id 75225, OS thread handle 0x7f5bbba39700, query id 118843266 www.ci.local 10.130.2.81 portal Sending data
SELECT 1 AS expression
FROM
views_content_cache views_content_cache
WHERE ( (c1 = 'pracownik') AND (c2 = 'node_changed') ) FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 98689 n bits 80 index "c1" of table "strona_ug"."views_content_cache" trx id 5701C073 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 9; hex 707261636f776e696b; asc pracownik;;
1: len 6; hex 00000b141f12; asc       ;;
drumm’s picture

Version: » 7.x-3.x-dev
Assigned: Unassigned » drumm
Status: Active » Closed (cannot reproduce)

This hasn’t been a problem lately.