Open chillu opened 3 years ago
Looks like we're creating around 400MB of QueuedJobDescriptor
entries per day :(
There's a Symbiote\QueuedJobs\Jobs\CleanupJob
configured to clean out after three days though, so I can't see how we've ended up accumulating 20GB of data there. Will need to keep an eye on the growth.
SELECT COUNT(*) FROM Addon WHERE Name IS NULL;
+----------+
| COUNT(*) |
+----------+
| 86 |
+----------+
1 row in set (0.00 sec)
That's really weird, and potentially a contributor to the log accumulation (hard to tell cause and effect with queuedjobs). I've added a guard for this in the pull request (not live yet), and cleaned out those entries for now. Might have been faulty or empty packagist responses that didn't get picked up by Guzzle as an HTTP error before processing them?
DELETE FROM Addon WHERE Name IS NULL;
I've also created an empty slate again on the production jobs to see how it behaves (TRUNCATE QueuedJobDescriptor
).
With the PR running in UAT, it appears that we've been rate limited quite heavily by packagist (2req/min), which makes it impossible to diagnose the long running task issues now. Will keep monitoring the situation.
The UAT server seems to repeatedly run out of memory, it only has 1GB. But the PR introduces a generator approach for the memory intensive packagist data. My hope is that it'll fix the issue, and allow us to perform a full UpdateAddonsTask
run on UAT.
But the PR introduces a generator approach for the memory intensive packagist data
Do you have any suggestions for improving this at the Packagist PHP SDK level? I'm happy to have a look at that
Thanks Robbie! I think I've gotten through it now with the latest commits in https://github.com/silverstripe/addons.silverstripe.org/pull/255.
We could still be more efficient in our Packagist API usage in two ways:
AddonUpdater
, use the statically generated files in https://packagist.org/p/silverstripe/framework.json rather than the larger/richer API responses in https://packagist.org/packages/silverstripe/framework.json. Technically we only need the full data in AddonBuilder
. The Packagist API docs say they prefer consumers to stick to those static files.If we're still getting rate limited after the latest round of fixes, I might need to look at that second option there.
Still happening on the same two repos, even without any interference by rate limiting and HTTP errors. The weird thing is that I can't really see what version constraint would be invalid there. It's these two payloads:
https://packagist.org/packages/dylangrech92/seotoolbox.json https://packagist.org/packages/unclecheese/silverstripe-kickassets.json
When "extracting" a composer.json out of a version there (mainly for the require
statements) and running composer validate
, you don't get any errors on the constraints. Example:
{
"name": "dylangrech92/seotoolbox",
"description": "This plugin was created to facilitate SEO work by automating most of the manual labor",
"keywords": [
"seo",
"reporting",
"silverstripe",
"Toolbox",
"automated links",
"seo testing"
],
"homepage": "https://github.com/dylangrech92/seotoolbox",
"version": "dev-develop",
"license": [
"BSD-3-Clause"
],
"authors": [
{
"name": "Dylan Grech",
"email": "dylangrech92@gmail.com",
"homepage": "https://innovativecodes.com/websites-marketing-and-more/dylan-grech",
"role": "Developer"
}
],
"type": "silverstripe-module",
"support": {
"issues": "https://github.com/dylangrech92/seotoolbox/issues",
"email": "dylangrech92@gmail.com",
"docs": "https://github.com/dylangrech92/seotoolbox/tree/master/docs",
"source": "https://github.com/dylangrech92/seotoolbox"
},
"time": "2016-10-14T05:22:22+00:00",
"extra": {
"installer-name": "seotoolbox"
},
"require": {
"php": "^5.3.0",
"silverstripe/cms": "^3.2",
"silverstripe/framework": "^3.2",
"undefinedoffset/sortablegridfield": "^0.6.2",
"silverstripe/html5": "^1.0.4"
}
}
AddonsUpdater
started failing around 30th of Oct in prod, without us changing anything obvious in code. Composer v2 was announced 24th of Oct. The timing is too close to be coincidence.Theory A: Packagist made subtle changes to their API responses Theory B: Packagist introduced harsher rate limit or connection terminations on large volume API requests
Job log error (note that this happens without a precending connection error):
Raygun error: https://app.raygun.com/crashreporting/1jsbyna/errors/4786298554?correlationId=426936499138&occurredOn=2020-11-18T00:06:13.0000000Z
Working through this in https://github.com/silverstripe/addons.silverstripe.org/pull/255. We might need to update to composer v2, although it's unclear what fails.