The purge ran one DELETE over the whole retention cutoff in a single
transaction, spiking undo/binlog and holding row locks on a table the
fetch cron writes to. Now it loops in batches of 5000 rows with a short
pause between batches, keeping each commit small.
- global_stats() executed the 'last N seconds' COUNT twice per page
load (prepare()->execute() result was discarded, then re-run)
- fetch_upstream_version() cached nothing on failure, so an
unreachable git server added a cURL wait (up to 5 s) to every
dashboard load via the 30 s auto-refresh; failures are now cached
for 15 minutes and get a 2 s connect timeout
Replace one INSERT per event (up to FETCH_LIMIT auto-committed
round trips per node per poll) with multi-row INSERTs in chunks of
200, wrapped in a single transaction per node. Same data, one
commit instead of hundreds, which was making fetch runs slower as
the table grew.
daprogs
DAProgs