Everything High Memory Usage Large Index: How to Fix It

When voidtools Everything uses a large amount of RAM, the cause is usually not a conventional memory leak. Everything keeps its filename index database in memory while it is running, so memory consumption naturally grows with the number of indexed files and folders. Optional property indexes, folder size indexing, duplicated folder indexes, and an enormous visible result list can increase usage further.

The safest response is to identify which part of the workload is large before rebuilding anything. Confirm the process, record a baseline, inspect the index configuration, and make one change at a time. This guide focuses specifically on Everything high memory usage with a large index. It also explains related symptoms such as missing results or an index that is not updating, without confusing Everything with the separate Windows Search service.

1. Confirm the Symptom With a Small Safe Test

Open Windows Task Manager and locate the Everything process. Depending on your configuration, you may also see an Everything service process. Add the Memory, Commit size, and Architecture columns if they are available. Confirm that the memory belongs to Everything rather than Windows Search, a file manager, or an antivirus process scanning the database.

Everything and Windows Search are different products. Windows Search maintains its own content-oriented index and powers features such as Start menu and File Explorer searches. Everything primarily builds a fast filename index. Restarting or rebuilding Windows Search will not normally reduce Everything's database size.

1.1 Record a useful baseline

Before changing settings, write down the following:

• Everything's memory usage after startup has settled
• The number of indexed objects shown in the status bar or index information
• Whether an empty search displays millions of results
• Whether memory rises only after running a broad search
• Whether the installed executable is x86 or x64
• Which NTFS volumes and folder indexes are enabled
• Whether optional properties or folder sizes are indexed

Now run a narrow, harmless search for a filename you know exists. Then clear the search box and, if necessary, use a restrictive filter instead of leaving every indexed item visible. Watch Task Manager during both operations.

If memory is high immediately after startup and remains relatively stable, the in-memory database is probably the main cost. If it increases sharply when an empty or very broad search produces millions of visible rows, the result list is contributing. If it climbs continuously while the index count also grows unexpectedly, look for duplicate, recursive, or unnecessary folder indexes.

1.2 Know what a successful test looks like

A successful baseline gives you a repeatable pattern. For example, Everything might settle at a consistent amount of memory after startup, rise during an unrestricted search, and fall partially after narrowing the results or restarting. Once the behavior is repeatable, stop experimenting and investigate the matching category. Do not change unrelated options simply because they appear technical.

2. Check the Index and Search Options That Directly Affect Memory

Open Everything's Options window and inspect the Indexes pages. The exact layout can vary by release, so use the option names visible in your installation rather than relying on screenshots from another build. The goal is to understand what Everything has been asked to retain in its database.

2.1 Use an x64 build for a genuinely large database

A 32-bit process has a much smaller practical address space than a 64-bit process. For very large Everything databases, the x64 build is the appropriate choice on 64-bit Windows. Switching architecture does not make the same database inherently tiny, but it gives Everything enough address space to manage a large index more reliably.

Check the Architecture column in Task Manager or use Everything's About information. If a 32-bit build is indexing many millions of objects, install or test the official x64 build that matches your preferred installed or portable setup. Preserve your configuration until you have confirmed the new executable is reading the intended settings.

Success means the x64 process starts correctly, loads the expected indexes, returns known files, and remains stable. If those conditions are met, stop changing architecture-related settings. High but stable memory can still be normal for the database size.

2.2 Prune unnecessary indexed folders

Every indexed object has a memory cost. Review indexed NTFS volumes and manually added folders for content you do not need to search. Common candidates include backup snapshots, application caches, build-output trees, package caches, virtual machine directories, duplicated archive mirrors, and large NAS shares that are rarely searched.

Be especially alert to the same content being represented more than once. For example, a local NTFS volume might already be indexed natively while one of its subfolders has also been added as a separate folder index. A share might also expose a tree that is indexed through another path.

Remove only indexes you understand. Do not exclude a folder merely because it is large if you depend on searching it. After removing an unnecessary index, allow Everything to update and compare both the object count and steady-state memory with your baseline.

Success is a lower index count that corresponds to the content you deliberately removed, with wanted files still searchable. If the reduction is expected and memory stabilizes, stop. Do not keep pruning useful locations solely to chase an arbitrary RAM number.

2.3 Review optional property indexes

Everything can index additional properties to make certain searches and sorts faster. Those indexes trade memory and database space for performance. If you have enabled properties that you rarely query, review whether their benefit justifies their cost.

Keep properties that support real workflows. Remove only optional indexes you recognize and do not need. After changing a property index, Everything may need time to rebuild or repopulate relevant data. Test the searches and sorts that previously used that property before deciding the change was harmless.

Success means normal filename searches still work, required property queries remain available, and memory settles below the baseline after indexing completes. If removing a property damages an important workflow, restore it rather than accepting slower or incomplete results.

2.4 Treat folder size indexing as a deliberate tradeoff

Folder sizes are not simple filename metadata. Calculating and retaining them can require substantial work across large directory trees. Folder size indexing is therefore a particularly important setting to inspect when Everything has a huge index.

If you do not routinely search or sort by folder size, disable the corresponding folder size indexing option and retest. If you need it only for a smaller tree, consider narrowing the indexed scope where your Everything version and configuration permit it. Do not repeatedly force folder size calculations while measuring idle memory, because that mixes active computation with the steady database cost.

Success means folder size processing finishes or is no longer scheduled, memory stops rising for that task, and ordinary filename results remain intact.

2.5 Limit oversized result lists

The index is not the only memory consumer. Clearing the search box can ask Everything to display every matching object. With millions of rows, the visible result list, sorting state, and associated UI data can add meaningful memory use.

Use a specific path, extension, filename fragment, or filter instead of displaying the entire database. Avoid sorting millions of results by a property that must be gathered or maintained. If memory rises only after a broad query, close that result set, run a narrow search, and compare again.

Success means a constrained query returns quickly and the process no longer experiences the same large query-related increase. This will not remove the base in-memory database, so expect some RAM to remain allocated.

3. Check Services, Servers, Portable Settings, and Windows Context

If the index size looks reasonable but behavior differs between launches, inspect how Everything is being started and which configuration it is using. Installed, portable, service-assisted, and server-oriented setups can behave differently because of account context and configuration location.

3.1 Distinguish the Everything service from the user interface

The Everything service can provide low-level access needed to index NTFS volumes without running the main interface as an administrator. Confirm that the service state matches your intended setup. Repeatedly launching additional instances under different accounts can make diagnosis confusing and may create separate processes or configurations.

Check Task Manager and the Windows Services console for unexpected duplicate instances. Close only instances you recognize, then start Everything using your normal shortcut. Avoid disabling the service blindly if your NTFS indexing setup depends on it.

Success means one expected user interface is connected to the intended service or indexing mode, known files appear, and memory readings are attributable to clearly identified processes.

3.2 Check portable configuration and startup arguments

A portable copy may store configuration near its executable, while an installed copy may use profile-specific locations. A shortcut, script, scheduled task, or command-line option can also select a different configuration, database, instance name, or startup behavior.

Inspect the shortcut target and any automation that launches Everything. Look for unrecognized command-line switches or references to another executable copy. Also check whether both an installed build and a portable build start when you sign in.

A successful correction leaves one intended copy loading one known configuration. The index count should remain consistent across restarts instead of changing depending on which shortcut you use.

3.3 Review network shares and folder indexes

Everything cannot use NTFS journal indexing on an ordinary remote share in the same way it can on a local NTFS volume. NAS folders and mapped drives are commonly added as folder indexes or searched through an Everything server. Large remote trees can therefore increase index size, scanning work, and update complexity.

Verify that mapped drive letters resolve under the same Windows account that runs Everything. Services and elevated processes may not see mappings created in a standard interactive session. When possible, use a stable UNC path for a folder index rather than relying on an account-specific drive letter.

If you use an Everything server, confirm that you are not also indexing the same remote content locally unless that duplication is intentional. Keep file-search servers restricted to trusted networks and authenticated or otherwise protected according to the product's supported configuration. Do not expose a search server directly to the public internet merely to simplify access.

Success means each remote tree appears once, updates under the intended account, and does not multiply the object count. Stop changing network settings when a known remote file appears once and subsequent changes are detected reliably.

3.4 Consider permissions, antivirus, and file system type

Permission problems more often cause missing or stale results than high steady-state memory, but they can lead users to add duplicate indexes as a workaround. Confirm that the account or service can access the selected location. For a folder index, test access using the same account context that runs Everything.

NTFS volumes can use Everything's fast NTFS indexing capabilities. Other file systems, removable media, and network storage may require folder indexing and periodic rescans. That distinction can affect update behavior and resource use.

Security software may scan Everything's database or executable, particularly during a rebuild. Check your security product's logs before making exclusions. If a narrowly scoped exclusion is genuinely necessary, follow your organization's policy and use only trusted Everything files and database locations. Never disable antivirus or endpoint protection permanently as a troubleshooting step.

4. Use Everything's Diagnostic Tools Methodically

Once the obvious index costs have been reviewed, use Everything's own status information and diagnostic features. The purpose is to gather evidence, not to activate every troubleshooting option simultaneously.

4.1 Read the status bar and Options pages

The status bar can reveal the number of results and whether Everything is busy. Compare the result count for an empty search with the indexed object information shown in the relevant Options pages. A surprisingly large total often points to a broader-than-intended scope or duplicated content.

Review exclusions as well as inclusions. An exclusion can explain Everything results missing, while an ineffective exclusion can leave a massive unwanted tree in the database. Test exclusions with one known included file and one known excluded file.

4.2 Test search syntax before blaming the index

A filter, search modifier, match-case option, whole-word option, path matching mode, or regular expression can make valid files appear missing. Reset the active filter and run a simple literal filename search. Then test a path-restricted query for a known location.

If the file appears after clearing the filter, the index is working and the problem is query state. If it remains absent, inspect the location's index configuration, exclusions, and update status. This distinction prevents unnecessary rebuilds.

4.3 Use Force Rebuild only after configuration checks

A force rebuild can resolve a damaged or inconsistent index, but it temporarily increases disk activity and may raise resource use while the database is recreated. Before using it, confirm that the correct volumes and folders are selected, the account can access them, and optional indexes are configured as intended.

Do not begin by deleting the database manually. Use the application's supported rebuild control first. During rebuilding, wait for indexing activity to finish before judging memory consumption.

Success means the index completes, the object count becomes stable, known files appear, and newly created test files are detected. If those checks pass, stop rebuilding. Repeated rebuilds will not make a correctly sized database smaller.

4.4 Use debug logging and the Index Journal selectively

Debug output can help identify repeated rescans, startup options, inaccessible paths, or update loops. Enable it only long enough to reproduce the problem, record timestamps, and note what action caused the increase. Logs themselves can become large, so turn verbose diagnostics off after collecting useful evidence.

The Index Journal can help determine whether a burst of file-system changes corresponds to memory or index growth. It is particularly useful when automated builds, synchronization tools, backups, or NAS processes generate large numbers of changes. Use the evidence to identify the changing tree instead of assuming the whole index is corrupt.

5. Run a Clean Temporary Test Before Broad Changes

If the cause remains unclear, run a clean temporary test using a separate Everything instance or temporary portable setup. Do not overwrite your working configuration or point two active instances at the same writable database file.

1. Download the appropriate official x64 build from voidtools.
2. Place a portable test copy in a new folder with its own configuration.
3. Start it as a separate test instance if your build supports that workflow.
4. Index one small, known local location first.
5. Record memory use and confirm that a test file appears.
6. Add one required volume, folder, property index, or remote location at a time.
7. Measure after each addition and stop when the large increase returns.

This controlled process isolates the expensive component without destroying your normal database. If the clean test remains small until a particular folder index or property is enabled, you have a strong explanation. If memory scales gradually with every batch of files, the main cause is probably the legitimate size of the in-memory database.

Success means you can name the setting or indexed tree that changes memory materially. At that point, choose between retaining the feature, narrowing its scope, or accepting the RAM cost. Do not migrate the test profile over your production configuration until searches, updates, service access, and remote paths all work as expected.

6. Quick Fix Checklist

• Confirm Task Manager shows Everything, not Windows Search, using the memory.
• Record the index count and idle memory before making changes.
• Use the official x64 build for a very large database on 64-bit Windows.
• Remove duplicate or unnecessary NTFS volumes and folder indexes.
• Review optional property indexes and retain only useful ones.
• Disable folder size indexing if you do not need folder size searches.
• Use narrow searches instead of displaying and sorting millions of results.
• Check for duplicate installed, portable, service, or scheduled instances.
• Confirm mapped drives and shares are visible to the running account.
• Verify exclusions with known included and excluded test files.
• Use the supported Force Rebuild command only after checking configuration.
• Run a clean temporary profile to isolate one setting at a time.

Stop troubleshooting when memory becomes stable, the index count matches the locations you intended to include, known files are found, and new files appear normally. Everything is designed to keep its active database in memory, so zero or negligible RAM use is not a realistic goal for a very large index.

7. Frequently Asked Questions

7.1 Why does Everything use so much RAM with a large index?

Everything keeps its filename index database in memory while running. A database containing many millions of files and folders therefore requires more RAM than a small index. Optional property indexes, folder size data, and a huge displayed result list can add to the total.

7.2 Is high memory usage proof of a memory leak?

No. High but stable memory that broadly tracks the index size is not, by itself, evidence of a leak. A stronger warning sign is memory that keeps growing without a corresponding change in indexed objects, searches, results, or active indexing work. Reproduce that pattern with a clean profile and collect debug information before reporting it.

7.3 Will Force Rebuild reduce memory usage?

Only if the existing database is inconsistent or contains stale data that a correct rebuild removes. If the rebuilt database contains the same objects and properties, its memory requirement will usually remain in a similar range. Rebuild to correct index integrity, not as a routine RAM optimization.

7.4 Why is Everything search not working after reducing the index?

You may have removed the volume or folder containing the file, enabled an exclusion, retained an active filter, or launched a different portable configuration. Search for a known literal filename with filters cleared, then verify the relevant location in Options. Restore only the required index rather than reverting every change.

7.5 Why is the Everything index not updating on a NAS?

NAS and network shares generally rely on folder indexing or a remote Everything server rather than local NTFS journal indexing. Check the folder index update settings, network availability, credentials, and account context. Confirm that the path is accessible to the process actually running Everything.

7.6 How much memory should Everything use?

There is no universal correct figure because usage depends on object count, path and filename characteristics, enabled properties, folder size indexing, current results, architecture, and workload. Compare your installation against its own clean baseline. A stable process that indexes the intended content and returns current results is a more useful success criterion than an arbitrary RAM target.