I finally joined the club of poor souls affected by slow 2026/27 performance.
I was doing an archive, and clearing a few pending renders would take minutes.
Good opportunity to debug, as it was repeatable. And I have a candidate for @Slabrie to take a look at. A possibly non-optimal database query.
Here are the debug steps. Anyone else affected could run these too to see if we find similar patterns.
Something is off…
Using mission center (graphical system performance tool) I noticed that while Flame was having lunch, the main disk (system NVME) was pegged at 100% activity, but was doing relatively little work - writing at 12MiB/s far below what a high performance NVMe can do. And it was all writes, no reads. So something was leisurely writing some files. And making everyone else wait until it was done.
But which ones?
Finding the files…
sudo dnf install bcc-tools -y
Then run
sudo /usr/share/bcc/tools/filetop -C 1 > /tmp/filetop_5.txt
This will take a snapshot of all file activity on the system by filename every second and append it to a file. Searching through that, the following file consistently shows up during the busy period:
TID COMM READS WRITES R_Kb W_Kb T FILE
93280 postgres 0 1421 0 11520 R 000000010000000000000044
So Flame is executing a Postgres query at the time. Which makes sense that this would affect 2026/27 consistently, since that coincides with the migration to Postgres.
Well, so what’s the query???
Login into Postgres server
sudo -u flame_db -i
Then run this command:
while true; do
psql -h /tmp -p 7533 -d postgres -c \
"SELECT clock_timestamp(), pid, now()-query_start AS running_for, state, query FROM pg_stat_activity WHERE state != 'idle';" \
>> /tmp/flame_pg_activity.log
sleep 2
done
It will dump queries that are running every 2 seconds. Look for a pattern.
Now we’re talking…
2026-09-06 11:50:03.175415+01 | 93280 | -00:00:00.000245 | active | UPDATE "a3af5823-20f1-43e5-8e56-d3620c4514fe".media SET refcount = refco
unt + 1 WHERE frameid IN (163208757485)
So it seems to be leisurely walking through those clips frame by frame and executing a query to update a reference count to indicate that frame is used somewhere.
Because it executes a query per frame it takes as long as it takes the cows to come home. In a good database schema that should be a single query per clip that can be executed in a fraction. May have to add a JOIN on tables and write a better WHERE condition. Pretty standard DB dev stuff.
Lets see if others can confirm this pattern.
Or there may be another query that is slooow running in some other scenarios where folks experienced a lunch break.
PS: It’s notable that this showed up for me after using a library rather than just desktop. On many projects, which are mostly short form, I just stay on the desktop but don’t update the library. This time I did, to unclutter the desktop. So it could be that this particular query only comes into play once a library is actively being used with files spanning desktop and libraries, and thus ref counts being required.