Tonight enwiki master db1052 load spiked with many concurrent oaiUpdatePage statements from jobrunners:
REPLACE /* oaiUpdatePage 127.0.0.1 */ INTO updates (up_page,up_action,up_timestamp,up_sequence) VALUES ('0','modify','20150421134316',NULL)
Notice up_page=0. The timestamp steadily increments. The production enwiki slaves do not show excessive lag, but this is likely due to the master throttling commit speed via the semi-synchronous replication plugin. Other slaves not in the semi-sync group (db1047, dbstore*) are showing replag. The REPLACE statements take up to 10s to commit at times as they fight for locks.
Other anecdotal info from IRC:
* MaxSem said up_page=0 is related to replag.
* legoktm said SUL finalization started on enwiki around that time
* I didn't notice SUL traffic going slow, but perhaps this was some cumulative thing
We should find out how not to fill up binlogs with hordes of identical queries.