docs: fix cron-scheduler.md job-count drift (50->49, phantom PBS prune entry)
Live NocoDB now has 49 jobs/14 without a fixed time, not 50/15 - traced to a removed inventory row for a "PBS prune job" that never actually existed (confirmed against live data and the KB note, which states PBS runs no prune job at all). Updated counts and refreshed all three screenshots to match current state.
This commit is contained in:
1 parent
6b3bea7f6f
commit
9be8e25c3b
4 files changed
+4
-4
No files matched your search
Binary file not shown.
|
Before Width: | Height: | Size: 194 KiB After Width: | Height: | Size: 189 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 198 KiB After Width: | Height: | Size: 193 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 275 KiB After Width: | Height: | Size: 342 KiB |
@@ -1,4 +1,4 @@
|
|||||||
<!-- verified: 2026-09-06
|
<!-- verified: 2026-09-18
|
||||||
trilium : EJGewkYGStHf
|
trilium : EJGewkYGStHf
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@@ -11,7 +11,7 @@
|
|||||||
|
|
||||||
A Node-RED tab fetches the inventory straight from NocoDB's REST API at request time — no cache — and renders it as a 7×24 grid (Mon–Sun × 00:00–23:00). Each cell's color is a **computed load weight**, not a raw job count: base `1` per job, plus a duration-bucket weight, plus a resource-tag weight (`disk-intensive`=2, `cpu-intensive`=1.5, `network-intensive`=0.5, summed if a job carries more than one), plus a flat `+1` if the job's category is `backup` — disk I/O contention from an overlapping backup is judged a worse collision than two lightweight jobs sharing an hour, and the weight formula says so explicitly rather than pretending every job costs the same. Weights bucket into 4 color bands (green → yellow → orange → red) relative to the current busiest cell. Jobs whose time can't be resolved to a specific day+hour are excluded from the grid and listed separately rather than forced into a misleading cell.
|
A Node-RED tab fetches the inventory straight from NocoDB's REST API at request time — no cache — and renders it as a 7×24 grid (Mon–Sun × 00:00–23:00). Each cell's color is a **computed load weight**, not a raw job count: base `1` per job, plus a duration-bucket weight, plus a resource-tag weight (`disk-intensive`=2, `cpu-intensive`=1.5, `network-intensive`=0.5, summed if a job carries more than one), plus a flat `+1` if the job's category is `backup` — disk I/O contention from an overlapping backup is judged a worse collision than two lightweight jobs sharing an hour, and the weight formula says so explicitly rather than pretending every job costs the same. Weights bucket into 4 color bands (green → yellow → orange → red) relative to the current busiest cell. Jobs whose time can't be resolved to a specific day+hour are excluded from the grid and listed separately rather than forced into a misleading cell.
|
||||||
|
|
||||||
This is the real heatmap, not a description of it — 50 known jobs, 15 without a fixed time:
|
This is the real heatmap, not a description of it — 49 known jobs, 14 without a fixed time:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
@@ -20,11 +20,11 @@ This is the real heatmap, not a description of it — 50 known jobs, 15 without
|
|||||||
|
|
||||||
Jobs with no fixed time get their own list instead of a misleading grid cell:
|
Jobs with no fixed time get their own list instead of a misleading grid cell:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Both of those are Dashy's *rendered* view. This is the raw NocoDB table underneath it — the actual data structure, not the heatmap built from it:
|
Both of those are Dashy's *rendered* view. This is the raw NocoDB table underneath it — the actual data structure, not the heatmap built from it:
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
## Why A Manual Inventory Instead Of An Auto-discovered One
|
## Why A Manual Inventory Instead Of An Auto-discovered One
|
||||||
|
|
||||||
|
|||||||
Reference in new issue
Block a user