Keeping Lansweeper fast and responsive can feel like a balancing act. You want deep insights, but too much data can slow the system to a crawl. Today’s quick tech tackles one of the most common causes of performance issues: scanning too much high‑volume data, especially Windows event logs and performance metrics.
What is going on
Many admins notice CPU spikes on their scanning servers, rising database sizes, and slow dashboards or reports. These symptoms often trace back to heavy performance scanning or large volumes of Windows event logs being collected across the network. Both features generate massive amounts of information, and Lansweeper must store and index all of it in SQL.
Performance scanning stresses both the scan server and the database. The scan service works harder, raising CPU usage. At the same time, SQL receives rapid, repeated inserts that inflate tables and grow indexes. As these tables expand, queries take longer, deadlocks appear, and routine tasks slow down.
Windows event logs create an even bigger challenge. They are large, noisy, and unstructured. When Lansweeper ingests logs from every workstation, the database can grow from a few gigabytes into terabytes. Once the database grows, basic actions become difficult. Reports lag. Dashboards load slowly. Inserts time out. Backups and restores take hours or even days. The system becomes sluggish and unreliable.
How can I fix this
You can restore performance by reducing the amount of high‑volume data Lansweeper collects and cleaning up oversized tables.
-
Disable or reduce performance scanning
Only enable performance scanning on servers that truly need it. Critical systems like domain controllers, SQL servers, or production workloads benefit from these metrics. Most workstations do not. After disabling unnecessary performance scanning, monitor CPU and scan speed to confirm improvement.
-
Tune Windows event log scanning
Scan event logs only on key servers. Limit the scan to essential Event IDs, such as specific security events. This reduces noise and keeps the database small and efficient. Avoid collecting every Application, System, and Security entry from every machine.
-
Clean up large database tables
Follow Lansweeper’s cleanup guide to trim oversized tables and rebuild indexes. This removes old event log data and improves query performance. The guide also explains how to identify which tables consume the most space so you can tune scanning accordingly.
https://community.lansweeper.com/t5/troubleshooting-your/clear-tables-to-free-up-space-and-improve-p...
-
Limit long‑term retention
Keep only the data you need for short‑term reporting. If you require full event histories, store them in a platform built for log ingestion.
-
Use a dedicated SIEM or log aggregator
Tools like Sentinel, Splunk, or Elastic handle event logs far better than SQL. They compress data, index it efficiently, and offer deep analytics.
Lansweeper excels at asset discovery and inventory. It is not designed to store years of raw event logs. By narrowing what you scan and offloading logs to a SIEM, you keep your database lean, your scan server fast, and your environment stable.
