NodeRunner.exe hosts components of the SharePoint Server search system. Several NodeRunner processes can therefore be normal. High memory use is a symptom to investigate, not proof that the processes are leaking or that an arbitrary memory cap is safe.
Support boundary: SharePoint Server 2013 reached end of support on 11 April 2023. Microsoft no longer provides security updates or technical support for it. If this farm still matters to the business, the primary action is an upgrade or migration plan.
What NodeRunner is doing
SharePoint search divides work across components such as crawling, content processing, analytics, query processing and index management. NodeRunner provides the process host used by parts of that search topology.
The number of processes and their memory use depend on the topology, content, query load and farm health. Killing a process or forcing a low limit can make search unstable while leaving the cause untouched.
A safer diagnostic sequence
1. Confirm the affected server and role
Record the server name, SharePoint build, search topology, installed updates and time of the incident.
Use Central Administration or supported SharePoint PowerShell to identify which search components run on that server. Do not infer the component solely from a Windows process name.
2. Check whether the farm is under memory pressure
Look at available memory, paging, CPU, disk latency and the timing of crawls or content processing. Microsoft's SharePoint Server monitoring guidance lists counters and a structured approach to locating bottlenecks.
Check other services too. SQL Server, Distributed Cache, antivirus scanning or another application may be competing for the same resources.
3. Check Search health
Review crawl logs, failed search components, ULS logs, Windows event logs, recent topology or content-source changes, and available disk space for index components.
Correlate the process spike with a specific activity. A full crawl after a content change is a different problem from a component repeatedly failing and restarting.
4. Confirm antivirus exclusions and supported configuration
Real-time scanning of SharePoint and Search working locations can interfere with farm operation. Use Microsoft's exclusion guidance for the exact SharePoint Server version and your security team's approval. Do not disable antivirus across the server as a shortcut.
5. Prefer topology and capacity fixes
If the workload is legitimate, adjust crawl schedules, remove obsolete content sources, correct failed components or redesign the search topology. Add capacity only after evidence shows a resource bottleneck.
Do not paste an old NodeRunner configuration memory value into production. An undocumented cap can trade visible memory use for failed or recycled search components.
If immediate recovery is required
Use the organisation's incident process. Capture logs and topology first, confirm backups and identify the supported service restart procedure for the farm.
A restart may restore service, but it is recovery, not a diagnosis. Keep the evidence and reproduce the problem in a supported test environment where possible.
Because SharePoint 2013 is unsupported, even a successful NodeRunner workaround leaves the farm exposed to unresolved product and security risk.
Assess whether the destination should be SharePoint Server Subscription Edition, SharePoint in Microsoft 365 or another supported platform. Inventory customisations, authentication, search dependencies and content before choosing.
This article helps structure an investigation. It does not validate a particular memory limit, diagnose your farm remotely or make an unsupported SharePoint 2013 deployment safe.
If you are untangling a legacy SharePoint farm and need to separate incident recovery from migration decisions, join the SharePoint & Teams Admins Space.