claudetools/clients/scileppi-law/session-logs/2026-05-07-howard-sylvia-mac-mini-mail-memory.md

Scileppi Law — Sylvia's Mac mini: Apple Mail memory thrashing on 8 GB hardware

Date: 2026-05-07 Client: The Law Offices of Chris Scileppi (Syncro 9601863) Asset: Sylvias-Mini — Apple Mac mini, Mac14,3 (M2), 8 GB LPDDR5, 256 GB SSD, macOS 14.4.1 (23E224) GuruRMM site: Main Office (WEST-MEADOW-9025) Syncro ticket: #32262 — Resolved

User

• User: Howard Enos (howard)
• Machine: Howard-Home
• Role: tech

Summary

Sylvia reported applications crashing and macOS popping "your system has run out of memory" warnings. Diagnosis traced the cause to Apple Mail consuming all available system memory on a base 8 GB Mac mini: the user's mailbox cache had grown well past what 8 GB can hold, forcing constant compressed-memory swap and the low-memory popups.

Two attempts to reset Mail's Envelope Index and let it re-index from server confirmed the problem reproduces on a clean index — the mailbox itself is too large for this hardware, not just an index corruption.

Interim fix: disabled Mail accounts at the macOS level so Mail.app cannot relaunch and re-thrash the system. Sylvia is on webmail (browser-based Outlook on the Web) until a replacement Mac mini with 16/24 GB RAM is on her desk.

Hardware / OS context

• Mac mini Mac14,3 (M2 base config). 8 GB unified memory (LPDDR5, Hynix). Apple discontinued this 8 GB SKU; current M4 Mac mini base is 16 GB at the same price point with a 24 GB upgrade option.
• macOS 14.4.1 (23E224).
• 92.78 GB free of 228.27 GB SSD at time of diagnosis (so disk space was not the issue).
• Single user account: sylvia.

What we observed

• Mail.app virtual memory footprint exceeded 45 GB on an 8 GB system.
• Hang report captured during a freeze:
  • Main thread inside CIContext rendering a glyph cache.
  • Worker thread blocked in apfs_pagein — process waiting on disk to swap in pages.
  • Approx. 4.4 million swapouts in 9 minutes of uptime. macOS was paging continuously, which is why the entire system felt unresponsive even when the user wasn't doing anything.
• "Memory pressure" indicator pinned red. Compressed memory near max. App relaunches were taking minutes.

These are textbook symptoms of an undersized RAM pool servicing an oversized working set. The OS is fine; the hardware is fine; the application is just bigger than the machine it's on.

Why Mail specifically

Apple Mail keeps an Envelope Index (SQLite metadata) plus message caches under ~/Library/Mail/V10/. With a multi-year IMAP/Exchange mailbox that's been on this machine for a long time, that cache had grown to many GB on disk and was forcing the equivalent into RSS/virtual once Mail walked it. Office, Safari, OneDrive, etc. then had to fight Mail for what little RAM was left.

Other heavy apps on the system (Safari with many tabs, OneDrive sync) were contributors but not the root cause — Mail was always the top consumer and the one whose footprint kept climbing.

Fix attempts

Attempt 1 — Envelope Index rebuild

1. Quit Mail.
2. Backed up ~/Library/Mail/V10/MailData/Envelope Index* files (the SQLite DB and its WAL/SHM siblings) to a sibling Envelope Index.backup-2026-05-07/ folder.
3. Relaunched Mail. Mail recreated the index and began re-downloading message metadata from server.
4. Watched memory: footprint rose to ~7 GB, then ~11 GB, then ~12 GB before Mail crashed. Foreground footprint dropped to 46 MB on relaunch — Mail had been killed by the OS for memory pressure, not by the user.

Attempt 2 — let it sit

Reopened Mail, walked away. Came back to find footprint at 25 GB and climbing to 28 GB, with Mail showing "Downloading 349 messages..." and a status ETA of "69 hours" that kept growing as memory pressure increased. This is the smoking gun: the index was rebuilding, just nowhere near fast enough because every page in / page out cycle competed with the in-progress download. Mail's working set was bigger than physical RAM, so the more it loaded, the slower it got.

This second pass conclusively ruled out "just a corrupt index" — a clean index reproduced the same explosion. The mailbox itself is too large for 8 GB to hold, period.

Interim resolution (what we left the machine in)

1. Force-quit Mail.app.
2. System Settings → Internet Accounts → disabled the Mail toggle on Sylvia's account(s). With Mail disabled at the OS account level, Mail.app cannot fetch and cannot rebuild itself in the background. (Calendar/Contacts left enabled — those have a much smaller footprint.)
3. Verified Mail.app no longer auto-relaunched after a reboot.
4. Walked Sylvia through using outlook.office.com in Safari for daily mail. Webmail does the heavy work server-side; the Mac mini just renders a web page.

The Mac mini is usable in this state. It's not pleasant — 8 GB with Office + OneDrive + Safari is still tight — but it stays out of the red zone with Mail off.

Recommendation

Replace the Mac mini.

• Why not just buy more RAM: Mac mini RAM is unified and soldered. There is no upgrade path.
• Target spec: M4 Mac mini, 16 GB minimum (matches base config price of the previous 8 GB), 24 GB preferred. 256 GB SSD is fine for this user; 512 GB is a minor add for headroom.
• 16 vs 24 GB: 16 GB will fix today's problem. 24 GB is the safer floor for a workstation that runs Office + OneDrive + a heavy mailbox + a browser with many tabs simultaneously. Budget difference is small relative to the lifespan of the machine.
• Migration plan: Migration Assistant from old → new over wired Ethernet or Thunderbolt. After migration, reconfigure Mail with Download Attachments = None (Mail → Settings → Accounts → Account → Mail Behaviors / Mailbox Behaviors) so the local cache stays small and this can't recur even on a larger machine.

Quote and order to be tracked separately. Open item on the client PROJECT_STATE.md.

Related

• GuruRMM enrollment of this Mac mini was attempted earlier today and failed for unrelated reasons (no macOS installer route on the server, and Cloudflare bot challenge blocking the install one-liner). Documented separately at session-logs/2026-05-07-howard-gururmm-macos-installer-and-cf-bot-block.md (root). Once Mike ships the macOS agent, return to enroll the new Mac mini after migration.

Billing

• Ticket: #32262 — "Sylvia is having applications crash and getting errors regarding low memory."
• Status set: Resolved.
• Time: 1.0 hour onsite (product 26118 — Labor - Onsite Business, $175/hr).
• Per Mike's instruction: time was logged as a billable line item but not invoiced. Line item sits on the ticket un-invoiced for later disposition.

Syncro artifact	ID
Resolution comment	409686752
Ticket timer	39082403 (3600 s active, billable)
Line item	42350646 ($175.00 × 1.0, non-taxable)
Invoice	(none — deliberately skipped)

Follow-ups

• Mike: spec / quote / order replacement Mac mini (M4, 16 or 24 GB).
• Howard: when new Mac arrives, run Migration Assistant from Sylvias-Mini and reconfigure Mail with Download Attachments = None.
• Howard: enroll new Mac in GuruRMM (gated on Mike shipping macOS agent — see related session log).
• Howard: re-enable Mail in Internet Accounts on the new machine after migration is verified working.