I've attached a copy of the JMeter test plan I've used to test copying collections. You'll need a file specifying some users to make use of it (see 'Mahara users CSV' element in the test plan).
Adding a sleep to execute_sql() didn't make any difference from me (either with jmeter or a 4 user browser test) but I probably have a much smaller test db than you which might be making enough of a difference.
Did the deadlock messages from 'show engine innodb status' give anything useful?
Looking at the page/collection page logic, one thing it does is delete all rows in view_rows_columns before reinserting for a given view. If nothing exists in view_rows_columns for that view, the deletes would cause gap locks at the end of table. Which could then cause the following inserts to view_rows_columns to fail in the deadlock state we've seen.
I've attached a copy of the JMeter test plan I've used to test copying collections. You'll need a file specifying some users to make use of it (see 'Mahara users CSV' element in the test plan).
Adding a sleep to execute_sql() didn't make any difference from me (either with jmeter or a 4 user browser test) but I probably have a much smaller test db than you which might be making enough of a difference.
Did the deadlock messages from 'show engine innodb status' give anything useful?
Looking at the page/collection page logic, one thing it does is delete all rows in view_rows_columns before reinserting for a given view. If nothing exists in view_rows_columns for that view, the deletes would cause gap locks at the end of table. Which could then cause the following inserts to view_rows_columns to fail in the deadlock state we've seen.