daniel added a comment. This script show open one connection per db cluster, not one per wiki. If it does, that's a major bug. The change dispatcher makes use of the standard functionality provided by the LoadBalancer class, so the connections hsould be pooled. Maybe it fails to release the connection in some error case, leading to more error cases? I'll try look into it, but I'm not on my regular work schedule this week.
As to the performance issues: - rewriting the dispatch logic to rely on the job queue has long been on the todo list, see T48643: [Story] Dispatching via delayed jobs (instead of cron script) <https://phabricator.wikimedia.org/T48643>. It's not trivial to get right, though. - there is a proposal to significantly improve performance of the script, see T112245: [Task] Configure wikidata.org to rely on the wb_changes_subscription table for dispatching. <https://phabricator.wikimedia.org/T112245> - here's the epic for improving the dispatch process: T108944: [Epic] Improve change dispatching <https://phabricator.wikimedia.org/T108944> Regarding the PID lock: running one instance will not dispatch changes fast enough. The lag will build up. TASK DETAIL https://phabricator.wikimedia.org/T118162 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: jcrespo, gerritbot, daniel, aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
