Lightroom Classic 15.5.1: runaway memory (148 GB) while automatically resuming background image-analysis/culling of existing catalog

When my long-established Lightroom Classic catalogue (~183,000 images) is opened with the drive containing the original photographs online, Lightroom automatically begins a large background image-analysis/culling operation. I am not deliberately starting Assisted Culling.

During this operation Lightroom systematically reads original image files and its committed/private memory grows continuously. I have observed Lightroom reach approximately 148 GB Private Bytes, at which point Windows becomes extremely difficult to use.

If the originals drive is disconnected, the same catalogue remains stable at approximately 2 GB PB.

Clean Lightroom catalogues using photographs from the same physical drive and same original files behave normally: processing completes and memory stabilises. The problem reproduces in Lightroom Classic 15.4.1 and 15.5.1, and also with GPU acceleration disabled.

System

Windows 10 Pro 22H2
Intel Core i9-10900
64 GB RAM
NVIDIA RTX 2060 6 GB
Catalogue/previews on dedicated SSD
Originals primarily on large NTFS HDD (X:)

Controlled reproduction

With Lightroom closed, Private Bytes were ~284 MB.

I opened the affected catalogue with X: online and performed no editing. Private Bytes climbed:

284 MB → 585 MB → 4.4 GB → 8.3 GB and continuing

Heavy disk I/O occurred simultaneously against original photographs on X:. At 8.3 GB, Windows interaction was already becoming difficult, so I closed Lightroom normally rather than allowing it to continue toward the previously observed 148 GB.

Changing the collection displayed in Lightroom did not determine which originals were being processed. Lightroom continued reading unrelated photographs elsewhere in the archive.

Database evidence

I examined read-only copies of the .lrcat SQLite database before and after this controlled test.

Before the run, exactly 55,480 images had records in each of these tables:

AgLibraryImageEmbeddings
AgLibraryImageCullingScore
AgLibraryImageBestFrameScore
AgLibraryImageUndesiredScores

The membership was identical: the same 55,480 images had records in all four tables, with no partial cases.

In one sequence I found an exact processing boundary:

P1360661.RW2 — analysed
P1360662.RW2 — not analysed

After the short controlled runaway-memory test, all four table counts had changed identically:

BEFORE: 55,480
AFTER: 55,571

Thus Lightroom had analysed 91 additional images during the test.

Critically, the first newly processed image was P1360662.RW2 — Lightroom had resumed precisely at the previously identified analysis boundary.

Several of those 91 newly analysed images were also the exact files independently observed being read by Lightroom.exe in Windows Resource Monitor during the run, including:

P1020300-Edit.tif
N0022 (32)-Edit.tif
N0022 (32).dng
N0022-24.tif
N0022-24-Edit.tif

This provides a direct correlation between Lightroom's original-file I/O and creation of these four sets of image-analysis records.

Other tests

• GPU acceleration OFF — problem persists.
• Lightroom Classic 15.4.1 — problem persists.
• Lightroom Classic 15.5.1 — problem persists.
• Originals drive disconnected — affected catalogue stable at ~2 GB PB.
• New empty catalogue — stable at ~0.7 GB.
• New catalogue containing ~41,000 photographs — stable.
• Fresh catalogue containing 804 images from one of the same source folders involved in the runaway — stable.
• Old ~88 GB preview cache renamed and fresh previews generated — problem persists.
• Same RAW/DNG files involved in the runaway behave normally in a clean catalogue.

Expected behaviour

Background image analysis may legitimately consume CPU, disk I/O and temporary memory. However, memory should be released/reused or otherwise bounded so that a large analysis backlog can complete without exhausting system resources.

Actual behaviour

Lightroom appears automatically to resume a large outstanding image-analysis/culling workload in this mature catalogue. The analysis itself progresses, but committed memory grows rapidly as processing continues and is apparently not adequately reclaimed. It has reached approximately 148 GB Private Bytes, making the system effectively unusable.

Suspected issue

The evidence suggests that the trigger is a large outstanding image-analysis/culling workload. The defect appears to be unbounded or inadequately reclaimed memory while Lightroom processes that backlog.

This may be related to the existing Assisted Culling/Auto Analysis memory-leak reports, but my case differs because I am not initiating Assisted Culling: Lightroom automatically resumes this processing when the existing catalogue is opened and its originals are available.

I can provide the before/after SQLite queries, Resource Monitor screenshots, database counts and additional diagnostic information if useful.