Change Details

As I mentioned at T202715#4865835 , I believe our main cause of contention at the moment is the following query: ``` User::loadFromDatabase Lock wait timeout exceeded; try restarting transaction SELECT user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id FROM `user` LEFT JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id)) WHERE user_id = '388680' LIMIT 1 FOR UPDATE ``` I believe this could be related to the actor migration, and I belive to be a similar case to the contention with the comment table- the same locking mechanism is kept for when a single table was uses, however, because we guarantee that actor is never deleted, it creates extra contention. FOR UPDATE should be limited to user (?). For me this is not an unbreak now, but there has been >2500 cases in the last 7 days and may get worse as more rows are inserted on actor (?).

As I mentioned at T202715#4865835 , I believe our main cause of contention at the moment is the following query: ``` User::loadFromDatabase Lock wait timeout exceeded; try restarting transaction SELECT user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id FROM `user` LEFT JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id)) WHERE user_id = '388680' LIMIT 1 FOR UPDATE ``` As detailed in T214963#4918834, this seems to be due to VisualEditor's find-and-replace dialog submitting concurrent requests to the API's `action=options` endpoint. We also note that the same dialog doesn't avoid submitting useless requests when the user is not logged in. This seems to have been going on for some time; it has been confirmed in 1.33.0-wmf.3, and the ApiOptions part of T206098 may have been the same cause too.

As I mentioned at T202715#4865835 , I believe our main cause of contention at the moment is the following query: ``` User::loadFromDatabase Lock wait timeout exceeded; try restarting transaction SELECT user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id FROM `user` LEFT JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id)) WHERE user_id = '388680' LIMIT 1 FOR UPDATE ``` I believe this could be related to the actor migration, and I belive to be a similar case to the contention with the comment table- the same locking mechanism is kept for when a single table was uses, however, because we guarantee that actor is never deletedAs detailed in T214963#4918834, it creates extra contentionthis seems to be due to VisualEditor's find-and-replace dialog submitting concurrent requests to the API's `action=options` endpoint. FOR UPDATE should be limited toWe also note that the same dialog doesn't avoid submitting useless requests when the user (?)is not logged in. For me this is not an unbreak now,This seems to have been going on for some time; but thereit has been >2500 casesconfirmed in the last 7 days1.33.0-wmf.3, and may get worse as more rows are inserted on actor (?)the ApiOptions part of T206098 may have been the same cause too.