Allowed memory size of 134217728 bytes exhausted (tried to allocate 38671954 bytes) in rssutils:
I’ve seen the similar topic in relation to classes/urlhelper.php and read a few less helpful topics, though I’m seeing this every 10 minutes in relation to /classes/rssutils.php and the function below.
It might have started around the same time my PLESK did a regular package update on the server, that included a minor PLESK version update and Ubuntu going from 18.04.5 to 18.04.5.6 though I don’t really see the connection myself. No update to any TT files or anything else.
I am also seeing a random 10-25 feeds fall behind update wise (almost on a timer as well). Meaning they don’t get updated, there are always new attempts started (last_udate_started), but the (last_updated) date is not changing/is stuck and new entries are no longer fetched. I can resolve this by nulling the (last_update) field at what point those feeds updates (not sure what makes that different from TT trying again during a regular interval for the feed), just for another random batch to fail the same way 10-30 minutes later.
My install has some custom tweaks and need an update soon and clean-up to be in line with the latest version by fox… as to my uncategorized post (though all has been stable for a long time).
I’m looking for any two cents as to what I can look for to debug this further. I was first thinking it must be a specific feed bugging out… but every 10-11 minute on the spot confuses me as that sounds more like some internal maintenance trigger of sorts? What memory setting is this, is it PHP or a TTRSS config? Looking through my TT configs atm. to see what I customized. And why every 10 minutes. hmm.
you’re reporting an issue while using 3 year old code, with “custom tweaks”, on an unsupported setup, using god knows what kind of underlying stack. are you serious?
unless you can verify this issue still exists on a supported setup (= docker) or official demo, i’m not going to bother with whatever this is about.
Seeing I did decide to post this “3 year old code”, I guess I am serious enough as to at least ask for any tips before potentially breaking something more by attempting something crazy or to upgrade (I did expect what I’ve gotten so far though)
It’s not like it was “unofficial” when installed and as a testament to your code it’s been running fairly smooth… even with some tweaks… and things would “normally” not just break out of the blue I guess. Been trying to find out if PLESK did anything that could relate, but so far I think the closed to anything is PHP updating from 7.4 to 7.4.30 which minor in theory.
Before I shame myself to a dark corner, if you can find the strength to at least give me hint as to why such an error might occur every 10.x minutes on the clock (on any setup) I’d be grateful.
By the function name I would expect it’s related to a feed being parsed, though I find the interval strange with no feed being checked any more frequent than every 30 minutes (I guess that technically, more than one feed could be involved, though a big coincidence on the timing if so). Anyway, that’s all, thanks again for your time in either case, I do appreciate your amazing work on this tool for so many years.
On a serious extra note; do most your TT users now go Docker instead of native on Linux, that’s the new default? I presume there’s some performance loss if so, though maybe it’s minor. From one test I recall seeing in relation to PGSQL (unless that’s then still better to keep native) on native vs. docker, that would mean a 10-12% or so loss both on read and write speeds (though I’ve not really researched it yet and I might recall wrong of course).
