iMac18,3 (2017 27") · i5-7500 4 cores @ 3.4 GHz · 40 GB RAM · Radeon Pro 570 4 GB · Retina 5K 5120×2880 · macOS 13.7.8 · second pass measured 2026-09-13 18:30 CDT
Widened from the 13:56 pass, which asked only about MTG Arena. That version is archived at public/_archive/mac-slow-diagnosis-2026-09-13-1356/. Two of its rulings are revised below.
200 files per sample, 4 KB read from each, chosen at random from trees that had not been touched. Five independent runs across three directories, each with its own seed.
| Sample | Tree | Seed | ms per file | files/sec |
|---|---|---|---|---|
| Cold 1 | ~/Older Downloads HUGE | 7 | 17.20 | 58 |
| Cold 2 | ~/Older Downloads HUGE | 101 | 22.92 | 44 |
| Cold 3 | ~/Older Downloads HUGE | 202 | 19.90 | 50 |
| Cold 4 | ~/Archive | 303 | 22.68 | 44 |
| Cold 5 | ~/Music | 404 | 16.61 | 60 |
A bare 7200 rpm drive is specified around 8 to 12 ms for a random seek. The measured 17 to 23 ms sits above that, which is seek time plus queueing behind other work.
A latency figure means nothing until the instrument is shown to separate fast from slow. Three controls ran through the same Python code path.
| Control | Expectation | Measured | Result |
|---|---|---|---|
| Re-read the identical 200 files | Near zero, the page cache should hold them | 0.03 ms/file · 36,258/s | Instrument separates warm from cold by 430× |
Same test on /Volumes/T7 Shield | Sub-millisecond, it is a real SSD | 0.71 ms/file · 1,412/s | Confirms the boot volume is the outlier |
Same test on /Volumes/Black | Between the two | 1.65 ms/file · 606/s | Still 10× faster than the boot volume |
diskutil info disk2 reports Fusion Drive: Yes.
Boot volume, df -h /System/Volumes/Data: 872 Gi used of 957 Gi, 93% full, 69 Gi free
28 GB of flash has to cache macOS, every open app, Chrome, Firefox, Obsidian, and 40 loaded launch agents, against roughly 900 GB of data. Almost everything is cold almost all the time, and cold means the platter.
Independent of the disk, and it costs GPU on everything continuously. system_profiler SPDisplaysDataType -json:
| Field | Value | Meaning |
|---|---|---|
spdisplays_pixelresolution | 5120 × 2880 | The physical Retina 5K panel |
_spdisplays_pixels | 4096 × 2304 | The framebuffer actually being rendered |
_spdisplays_resolution | 2048 × 1152 | The logical desktop |
The display sits in a scaled mode, so macOS draws the whole desktop into a 4096×2304 buffer and rescales it onto a 5120×2880 panel at a non-integer ratio. That cost is paid on every frame of every app.
MTG Arena's own log records the knock-on at launch:
Current screen dimensions of 4096x2096 are not an allowable ratio (1.954198)
so we are forcing windowed mode.Metal RecreateSurface: surface size 3840x21604096×2096 is that framebuffer minus the menu bar and dock. Arena rejects the aspect ratio, refuses fullscreen, and settles on a 3840×2160 surface. Measured at 15:24 with Arena parked on its Home screen doing nothing: 125 to 138% CPU (1.3 of 4 cores) and GPU utilization bursting 78 to 99, with Graphics.GlobalQualityLevel and UnityGraphicsQuality both already at 0, the lowest the game offers.
| Ruling at 13:56 | Re-measured | Status |
|---|---|---|
| GPU ruled out: “0 to 63%, never pinned” | 78 to 99 sustained at 15:24, with the scaled framebuffer identified as the cause | Revised. The 13:56 sample caught it between bursts |
| Per-process disk I/O: UNATTRIBUTED | Still unattributed by process. Now attributed by device and by latency, which answers the question better | Upgraded, honestly incomplete |
| Spotlight ruled out: “idle maintenance” | mds and mdworker at 0.0 to 0.1% CPU, both external drives at 0 tps | Confirmed correct. See the near miss below |
mdworker_shared processes were live with three sitting in uninterruptible disk wait, and syspolicyd showed 198,699 pageins against mds_stores at 45,111. That reads like Spotlight hammering the disk. A 30 second delta test refuted it: pageins across every process totalled 108 in 30 seconds, 3.6 per second, which is nothing. Those counters are cumulative since boot, not rates. Publishing the first reading would have named the wrong culprit.| Suspect | Measured at 18:08 to 18:30 | Reading |
|---|---|---|
| Memory exhaustion | 19 GB unused | Zero swap, zero compressor, no paging |
| Heat and throttling | limit 100 | No thermal or performance warning ever recorded |
| CPU saturation | 49.6% idle | Load 2.49 on 4 cores, nothing above 5.4% |
| Spotlight indexing | 0.0 to 0.1% | Externals at 0 tps, index not being rebuilt |
| Memory paging | 3.6 pageins/s | Measured as a 30 second delta, negligible |
| Time Machine | Running = 0 | No backup in progress |
~/Older Downloads HUGE 108 GB, ~/Downloads 22 GB, ~/Archive 19 GB. Destination /Volumes/Black has 174 Gi free. Per the never-delete rule these move, nothing is removed. This gives the 28 GB flash tier room to promote what is actually in use.~/Library/LaunchAgents, 40 currently loaded, 9 resident. Each one wakes, reads its interpreter and scripts off the platter, and competes for the same seeks.Per-process disk I/O attribution needs fs_usage, which requires an administrator password, and sudo is not passwordless here. The device-level and latency-level attribution above does not name which process issues the cold reads. That remains UNATTRIBUTED.
Second pass, 18:08 to 18:30 CDT on 2026-09-13, uptime 4h32m. Every figure is observed command output. The latency benchmark and its controls are in pagein_delta.sh and inline Python, run read-only, modifying nothing.
diskutil info disk0 disk1 disk2 · df -h · iostat -d -w 2 -c 8 disk0 disk1 disk3 disk4 · top -l 2 -o cpu · top -l 1 -n 60 -o pageins sampled twice 30 s apart · ps -axo pid,stat,%cpu,comm · memory_pressure · pmset -g therm · mdutil -s · tmutil status · launchctl list · ioreg -r -d 1 -c IOAccelerator · system_profiler SPDisplaysDataType -json · sample 28197 5 · plutil -p com.wizards.mtga.plist · du -sh