wiki.techinc.nl/includes/ResourceLoader/dependencystore/SqlModuleDependencyStore.php

213 lines
5.9 KiB
PHP
Raw Normal View History

<?php
/**
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
*/
namespace Wikimedia\DependencyStore;
use InvalidArgumentException;
use Wikimedia\Rdbms\DBConnRef;
use Wikimedia\Rdbms\IDatabase;
use Wikimedia\Rdbms\ILoadBalancer;
/**
ResourceLoader: Remove DependencyStore::renew == Background When file dependency information is lost, the startup module computes a hash that is based on an incomplete summary of bundled resources. This means it arrives at a "wrong" hash. Once a browser actually asks for that version of the module, though, we rediscover the dependency information, and subsequent startup responses will include arrive once again at the same correct hash. These 5-minute windows of time where the browser cache of anyone visiting is churned over are not great, and so we try to avoid them. The status quo is the dedicated module_deps table in core with no expiry. This means a potential concern is building up gargage over time for modules and extensions that no longer exist or are no longer deployed on that wiki. In practice this has not been much of an issue, we haven't run the cleanupRemovedModules.php or purgeModuleDeps.php scripts in years. Once in 2017 to fix corrupt rows (T158105), and once in 2020 to estimate needed space if we had expiries <https://phabricator.wikimedia.org/T113916#6142457>. Hence we're moving to mainstash via KeyValueDepStore, and not to memcached. But for that we might as well start using experies. To not compromise on losing dep info regularly and causing avoidable browser cache for modules that are hot and very much still existing, we adopted `renew()` in 5282a0296 when drafting KeyValueDepStore, so that we keep moving the TTL of active rows forward and let the rest naturally expire. == Problem The changeTTL writes are so heavy and undebounced, that it fully saturates the hardware disk, unable to keep up simply with the amount of streaming append-only writes to disk. https://phabricator.wikimedia.org/T312902 == Future Perhaps we can make this work if SqlBagOStuff in "MainStash" mode was more efficient and lenient around changeTTL. E.g. rather than simultanously ensure presence of the row itself for perfect eventual consistency, maybe it could just be a light "touch" to ensure the TTL of any such row has a given minimum TTL. Alternatively, if we don't make it part of the generalised SqlBag/MainStash interface but something speciifc to KeyValueDepStore, we could also do something several orders of magnitudes more efficient, such as only touching it once a day or once a week, instead of several hundred times a second after every read performing a write that amplifies the read back into a full row write, with thus a very large and repetative binlog. == This change As interim measure, I propose we remove renew() and instead increase the TTL from 1 week to 1 year. This is still shorter than "indefinite" which is what the module_deps table does in the status quo, and that was never an issue in practice in terms of space. This is because the list of modules modules is quite stable. It's limited to modules that are both file-backed (so no gadgets) and also have non-trivial file dependencies (such as styles.less -> foo.css -> bar.svg). == Impact The installer and update.php (DatabaseUpdater) already clear `module_deps` and `objectcache` so this is a non-issue for third parties. For WMF, it means that the maintenance script we never ran, can be removed as it will now automatically clean up this stuff after a year of inactivity, with a small cache churn cost to pay at that time. Bug: T113916 Bug: T312902 Change-Id: Ie11bdfdcf5e6724bc19ac24e4353aaea316029fd
2022-07-11 21:20:22 +00:00
* Track per-module file dependencies in the core module_deps table
*
ResourceLoader: Remove DependencyStore::renew == Background When file dependency information is lost, the startup module computes a hash that is based on an incomplete summary of bundled resources. This means it arrives at a "wrong" hash. Once a browser actually asks for that version of the module, though, we rediscover the dependency information, and subsequent startup responses will include arrive once again at the same correct hash. These 5-minute windows of time where the browser cache of anyone visiting is churned over are not great, and so we try to avoid them. The status quo is the dedicated module_deps table in core with no expiry. This means a potential concern is building up gargage over time for modules and extensions that no longer exist or are no longer deployed on that wiki. In practice this has not been much of an issue, we haven't run the cleanupRemovedModules.php or purgeModuleDeps.php scripts in years. Once in 2017 to fix corrupt rows (T158105), and once in 2020 to estimate needed space if we had expiries <https://phabricator.wikimedia.org/T113916#6142457>. Hence we're moving to mainstash via KeyValueDepStore, and not to memcached. But for that we might as well start using experies. To not compromise on losing dep info regularly and causing avoidable browser cache for modules that are hot and very much still existing, we adopted `renew()` in 5282a0296 when drafting KeyValueDepStore, so that we keep moving the TTL of active rows forward and let the rest naturally expire. == Problem The changeTTL writes are so heavy and undebounced, that it fully saturates the hardware disk, unable to keep up simply with the amount of streaming append-only writes to disk. https://phabricator.wikimedia.org/T312902 == Future Perhaps we can make this work if SqlBagOStuff in "MainStash" mode was more efficient and lenient around changeTTL. E.g. rather than simultanously ensure presence of the row itself for perfect eventual consistency, maybe it could just be a light "touch" to ensure the TTL of any such row has a given minimum TTL. Alternatively, if we don't make it part of the generalised SqlBag/MainStash interface but something speciifc to KeyValueDepStore, we could also do something several orders of magnitudes more efficient, such as only touching it once a day or once a week, instead of several hundred times a second after every read performing a write that amplifies the read back into a full row write, with thus a very large and repetative binlog. == This change As interim measure, I propose we remove renew() and instead increase the TTL from 1 week to 1 year. This is still shorter than "indefinite" which is what the module_deps table does in the status quo, and that was never an issue in practice in terms of space. This is because the list of modules modules is quite stable. It's limited to modules that are both file-backed (so no gadgets) and also have non-trivial file dependencies (such as styles.less -> foo.css -> bar.svg). == Impact The installer and update.php (DatabaseUpdater) already clear `module_deps` and `objectcache` so this is a non-issue for third parties. For WMF, it means that the maintenance script we never ran, can be removed as it will now automatically clean up this stuff after a year of inactivity, with a small cache churn cost to pay at that time. Bug: T113916 Bug: T312902 Change-Id: Ie11bdfdcf5e6724bc19ac24e4353aaea316029fd
2022-07-11 21:20:22 +00:00
* Wiki farms that are too big for maintenance/update.php, can clean up
* unneeded data for modules that no longer exist after a MW upgrade,
* by running maintenance/cleanupRemovedModules.php.
*
ResourceLoader: Remove DependencyStore::renew == Background When file dependency information is lost, the startup module computes a hash that is based on an incomplete summary of bundled resources. This means it arrives at a "wrong" hash. Once a browser actually asks for that version of the module, though, we rediscover the dependency information, and subsequent startup responses will include arrive once again at the same correct hash. These 5-minute windows of time where the browser cache of anyone visiting is churned over are not great, and so we try to avoid them. The status quo is the dedicated module_deps table in core with no expiry. This means a potential concern is building up gargage over time for modules and extensions that no longer exist or are no longer deployed on that wiki. In practice this has not been much of an issue, we haven't run the cleanupRemovedModules.php or purgeModuleDeps.php scripts in years. Once in 2017 to fix corrupt rows (T158105), and once in 2020 to estimate needed space if we had expiries <https://phabricator.wikimedia.org/T113916#6142457>. Hence we're moving to mainstash via KeyValueDepStore, and not to memcached. But for that we might as well start using experies. To not compromise on losing dep info regularly and causing avoidable browser cache for modules that are hot and very much still existing, we adopted `renew()` in 5282a0296 when drafting KeyValueDepStore, so that we keep moving the TTL of active rows forward and let the rest naturally expire. == Problem The changeTTL writes are so heavy and undebounced, that it fully saturates the hardware disk, unable to keep up simply with the amount of streaming append-only writes to disk. https://phabricator.wikimedia.org/T312902 == Future Perhaps we can make this work if SqlBagOStuff in "MainStash" mode was more efficient and lenient around changeTTL. E.g. rather than simultanously ensure presence of the row itself for perfect eventual consistency, maybe it could just be a light "touch" to ensure the TTL of any such row has a given minimum TTL. Alternatively, if we don't make it part of the generalised SqlBag/MainStash interface but something speciifc to KeyValueDepStore, we could also do something several orders of magnitudes more efficient, such as only touching it once a day or once a week, instead of several hundred times a second after every read performing a write that amplifies the read back into a full row write, with thus a very large and repetative binlog. == This change As interim measure, I propose we remove renew() and instead increase the TTL from 1 week to 1 year. This is still shorter than "indefinite" which is what the module_deps table does in the status quo, and that was never an issue in practice in terms of space. This is because the list of modules modules is quite stable. It's limited to modules that are both file-backed (so no gadgets) and also have non-trivial file dependencies (such as styles.less -> foo.css -> bar.svg). == Impact The installer and update.php (DatabaseUpdater) already clear `module_deps` and `objectcache` so this is a non-issue for third parties. For WMF, it means that the maintenance script we never ran, can be removed as it will now automatically clean up this stuff after a year of inactivity, with a small cache churn cost to pay at that time. Bug: T113916 Bug: T312902 Change-Id: Ie11bdfdcf5e6724bc19ac24e4353aaea316029fd
2022-07-11 21:20:22 +00:00
* To force a rebuild and incurr a small penalty in browser cache churn,
* run maintenance/purgeModuleDeps.php instead.
*
* @internal For use by ResourceLoader\Module only
* @since 1.35
*/
class SqlModuleDependencyStore extends DependencyStore {
/** @var ILoadBalancer */
private $lb;
/**
* @param ILoadBalancer $lb Storage backend
*/
public function __construct( ILoadBalancer $lb ) {
$this->lb = $lb;
}
public function retrieveMulti( $type, array $entities ) {
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$dbr = $this->getReplicaDb();
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$depsBlobByEntity = $this->fetchDependencyBlobs( $entities, $dbr );
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$storedPathsByEntity = [];
foreach ( $depsBlobByEntity as $entity => $depsBlob ) {
$storedPathsByEntity[$entity] = json_decode( $depsBlob, true );
}
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$results = [];
foreach ( $entities as $entity ) {
$paths = $storedPathsByEntity[$entity] ?? [];
$results[$entity] = $this->newEntityDependencies( $paths, null );
}
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
return $results;
}
public function storeMulti( $type, array $dataByEntity, $ttl ) {
// Avoid opening a primary DB connection when it's not needed.
// ResourceLoader::saveModuleDependenciesInternal calls this method unconditionally
// with empty values most of the time.
if ( !$dataByEntity ) {
return;
}
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$dbw = $this->getPrimaryDB();
$depsBlobByEntity = $this->fetchDependencyBlobs( array_keys( $dataByEntity ), $dbw );
$rows = [];
foreach ( $dataByEntity as $entity => $data ) {
[ $module, $variant ] = $this->getEntityNameComponents( $entity );
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
if ( !is_array( $data[self::KEY_PATHS] ) ) {
throw new InvalidArgumentException( "Invalid entry for '$entity'" );
}
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
// Normalize the list by removing duplicates and sortings
$paths = array_values( array_unique( $data[self::KEY_PATHS] ) );
sort( $paths, SORT_STRING );
$blob = json_encode( $paths, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE );
$existingBlob = $depsBlobByEntity[$entity] ?? null;
if ( $blob !== $existingBlob ) {
$rows[] = [
'md_module' => $module,
'md_skin' => $variant,
'md_deps' => $blob
];
}
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
}
// @TODO: use a single query with VALUES()/aliases support in DB wrapper
// See https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html
foreach ( $rows as $row ) {
$dbw->upsert(
'module_deps',
$row,
[ [ 'md_module', 'md_skin' ] ],
[
'md_deps' => $row['md_deps'],
],
__METHOD__
);
}
}
public function remove( $type, $entities ) {
// Avoid opening a primary DB connection when it's not needed.
// ResourceLoader::saveModuleDependenciesInternal calls this method unconditionally
// with empty values most of the time.
if ( !$entities ) {
return;
}
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$dbw = $this->getPrimaryDB();
$disjunctionConds = [];
foreach ( (array)$entities as $entity ) {
[ $module, $variant ] = $this->getEntityNameComponents( $entity );
ResourceLoader: Fix confusing DependencyStoreException trace logs After the roll-out of $wgResourceLoaderUseObjectCacheForDeps on WMF wikis, there was an unrelated database spike that caused some error messages: > DependencyStoreException: > Cannot access the database: Too many connections (db1132) I found this confusing, because servers shouldn't be using old DepStore class any more (ref T311788?). And because the new store is x2.mainstash, whereas the reported hostname is an s1.enwiki host. I wasted some time not trusting the code path as there was no Rdbms trace available to confirm for sure that this isn't an unrelated query that happens to be caught during the DepStore interaction (e.g. some generic MW code running from a hook, or Rdbms internal query from LoadMonitor etc). Improve telemetry by preserving the original trace. I considered passing `$e` as third parameter to DependencyStoreException, but since the new implementation doesn't actually use this class, it's effectively going to remain unused in the future and would not reliably indicate anything in particular to callers unaware of which implementation is in use. There's also some benefit to being able to aggregate and filter out specific db issues, which is made harder by the same issue being reported multiple different ways through wrapped errors. The old implementation will remain for one release as default, and probably one release after that as option for any third parties that encounter an issue during upgrade so as to not block their upgrade while we find/address the issue in question. Bug: T113916 Change-Id: Iaa3907fc3aa0622daa9648eabfdd7efabdd4f2a9
2022-07-28 02:41:09 +00:00
$disjunctionConds[] = $dbw->makeList(
[ 'md_skin' => $variant, 'md_module' => $module ],
$dbw::LIST_AND
);
}
if ( $disjunctionConds ) {
$dbw->delete(
'module_deps',
$dbw->makeList( $disjunctionConds, $dbw::LIST_OR ),
__METHOD__
);
}
}
/**
* @param string[] $entities
* @param IDatabase $db
* @return string[]
*/
private function fetchDependencyBlobs( array $entities, IDatabase $db ) {
$modulesByVariant = [];
foreach ( $entities as $entity ) {
[ $module, $variant ] = $this->getEntityNameComponents( $entity );
$modulesByVariant[$variant][] = $module;
}
$disjunctionConds = [];
foreach ( $modulesByVariant as $variant => $modules ) {
$disjunctionConds[] = $db->makeList(
[ 'md_skin' => $variant, 'md_module' => $modules ],
$db::LIST_AND
);
}
$depsBlobByEntity = [];
if ( $disjunctionConds ) {
$res = $db->newSelectQueryBuilder()
->select( [ 'md_module', 'md_skin', 'md_deps' ] )
->from( 'module_deps' )
->where( $db->makeList( $disjunctionConds, $db::LIST_OR ) )
->caller( __METHOD__ )->fetchResultSet();
foreach ( $res as $row ) {
$entity = "{$row->md_module}|{$row->md_skin}";
$depsBlobByEntity[$entity] = $row->md_deps;
}
}
return $depsBlobByEntity;
}
/**
* @return DBConnRef
*/
private function getReplicaDb() {
return $this->lb
->getConnectionRef( DB_REPLICA, [], false, ( $this->lb )::CONN_TRX_AUTOCOMMIT );
}
/**
* @return DBConnRef
*/
private function getPrimaryDb() {
return $this->lb
->getConnectionRef( DB_PRIMARY, [], false, ( $this->lb )::CONN_TRX_AUTOCOMMIT );
}
/**
* @param string $entity
* @return string[]
*/
private function getEntityNameComponents( $entity ) {
$parts = explode( '|', $entity, 2 );
if ( count( $parts ) !== 2 ) {
throw new InvalidArgumentException( "Invalid module entity '$entity'" );
}
return $parts;
}
}