How to Use the DiskStation Manager Resource Monitor to Spot Bottlenecks
A Synology NAS can appear slow for many different reasons. Large file transfers, media streaming, backup jobs, RAID checks, database activity, and cloud synchronization may compete for the same CPU, memory, storage, or network resources. Guessing at the cause often leads to unnecessary upgrades or poorly targeted configuration changes.
DiskStation Manager (DSM) includes Resource Monitor, a built-in diagnostic tool that helps connect performance symptoms with actual system activity. It displays usage trends for processor load, memory, disks, volumes, network interfaces, and running processes. With a methodical approach, these readings can reveal whether a bottleneck is caused by hardware limits, a busy service, a scheduled task, or a network problem.
The most useful results come from monitoring during the slowdown rather than checking the NAS after the problem has ended. Record normal activity first, then compare it with the readings captured during file transfers, backups, Plex activity, RAID maintenance, or other demanding workloads.
Opening Resource Monitor In DSM
Sign in to DSM with an account that has suitable administrative privileges. Open the main menu and select Resource Monitor. Depending on the DSM release and device model, the layout may include tabs or panels for Overview, Performance, Storage, Network, and Processes. The names and available details can vary slightly between DSM versions.
The Overview screen provides a quick view of current CPU, memory, disk, and network activity. It is useful for identifying an obvious problem, such as processor usage staying near full capacity or a volume showing sustained disk activity. However, a short snapshot can be misleading, so use the graphs and change the displayed time range when possible.
Begin by observing the NAS while it is idle. Then reproduce the performance issue with a controlled task, such as copying a large file, starting a backup, opening a media stream, or running an application. Note the exact time and activity so you can match the symptom to a spike in Resource Monitor.
Reading CPU, Memory, And System Load
CPU utilization shows how heavily the NAS processor is being used. High CPU activity during video transcoding, thumbnail generation, antivirus scanning, compression, or encryption may be expected. A sustained high reading during ordinary file sharing, however, suggests that a service or process deserves closer inspection.
A brief CPU spike is usually harmless. The more important pattern is prolonged usage near the processor’s maximum, especially when file operations become slow and the system interface responds sluggishly. On multi-core systems, overall utilization can conceal a single busy core, so process-level details are valuable when an application appears slow even though the total percentage looks moderate.
Memory usage requires a different interpretation. DSM uses available RAM for caching, so high memory consumption alone does not necessarily indicate a fault. Look for low available memory, increasing swap activity, and processes whose memory usage continues to grow. If applications are repeatedly stopped or the NAS becomes unresponsive, insufficient RAM or a memory-heavy package may be involved.
Tracking Disk, Volume, And RAID Activity
Disk performance is often the main limitation during NAS workloads. Resource Monitor can show read and write activity for individual drives, storage pools, and volumes. Sustained utilization near the device’s practical limit, high response times, or a long queue of pending operations can indicate storage contention.
A single large transfer may saturate the network without creating a serious disk problem. In contrast, many small files, database transactions, virtual machines, and photo indexing tasks create random input/output operations that can make disks feel slow even when throughput appears modest. Hard disk drives are especially sensitive to this pattern because their mechanical heads must seek between locations.
RAID operations can temporarily dominate storage resources. Data scrubbing, parity checks, pool expansion, drive replacement, and RAID rebuilding may continue in the background while other services remain available. These processes protect or maintain the array, but they can reduce responsiveness and transfer speeds until they finish.
| Resource Monitor Signal | Likely Bottleneck | Common Causes | Useful Next Check |
|---|---|---|---|
| CPU remains very high | Processor capacity | Transcoding, indexing, encryption, antivirus, compression | Review Processes and package activity |
| Memory stays nearly full with swap use | RAM pressure | Many packages, containers, databases, virtual machines | Check process memory and reduce concurrent services |
| Disk activity stays high with slow response | Storage I/O contention | RAID maintenance, backups, databases, many small files | Identify busy volume and active task |
| Network traffic reaches interface limit | Network bandwidth | Large transfers, multiple clients, sync jobs | Check link speed, switch, cables, and clients |
| One process repeatedly spikes | Service-specific load | Media indexing, synchronization, snapshots, scans | Pause or reschedule the responsible task |
| Normal resource use but poor transfer speed | Configuration or external limit | Wi-Fi, SMB settings, client disk, failing cable | Test another client and wired connection |
Comparing Network Throughput With Workloads
The Network view helps determine whether the NAS or the connection is limiting performance. Check the interface receiving or sending traffic, current throughput, packet activity, and the timing of the slowdown. A gigabit Ethernet connection has a theoretical limit of 1 Gbps, but protocol overhead, client storage, and network conditions reduce real-world file transfer speeds.
When network traffic approaches the practical capacity of the link while CPU and disk usage remain moderate, the bottleneck is probably network-related. Confirm that the NAS negotiated the expected link speed and that the switch, cabling, and client are also capable of supporting it. A damaged cable or a connection that has fallen back to a lower speed can create a major performance difference.
Wireless clients frequently introduce another limit. A NAS connected by Ethernet may be operating normally while a laptop or streaming device is constrained by Wi-Fi signal quality, interference, or an older wireless standard. Compare the same operation from a wired client before changing NAS settings.
Finding Busy Services And Processes
The Processes view connects resource usage with specific applications. Sort processes by CPU, memory, or disk activity to identify the largest consumers. Depending on the DSM version, system processes and package processes may be listed separately, and some activities may appear under a general service name rather than the task that initiated them.
Common sources of unexpected load include Synology Drive indexing, Universal Search, Synology Photos analysis, Hyper Backup, Active Backup, Snapshot Replication, Download Station, Docker or Container Manager workloads, and media server scanning. A process that becomes active immediately after new files are added may be performing indexing or thumbnail generation rather than malfunctioning.
Scheduled tasks should be considered as well. A nightly backup, cloud synchronization job, integrity check, or antivirus scan can overlap with working hours if its schedule was changed or if the previous run lasted longer than expected. DSM’s Task Scheduler and package-specific activity pages can help confirm whether a recurring job matches the Resource Monitor pattern.
Turning Measurements Into Targeted Fixes
A useful diagnosis compares several indicators at the same time. For example, high network throughput with moderate disk activity points toward a link or client limit, while high disk response time and low network throughput suggest storage contention. High CPU and a single busy service indicate a different remedy from high memory use across many applications.
Avoid treating every performance spike as evidence of failing hardware. Maintenance operations, cache warm-up, indexing, and backups can create legitimate temporary load. Check whether the activity ends normally, whether it occurs on a predictable schedule, and whether the NAS returns to its usual baseline afterward.
Use these practical steps when investigating a slowdown:
- Record idle CPU, memory, disk, and network readings before testing a workload.
- Reproduce the problem with one major task at a time and note the start and end times.
- Sort processes by CPU, memory, and disk activity to find the service associated with each spike.
- Reschedule backups, indexing, scrubbing, and scans so they do not overlap with peak usage.
- Test the same transfer from a wired client and inspect the negotiated network link speed.
If the readings remain abnormal after packages and scheduled tasks have been reviewed, examine storage health in Storage Manager. Check drive S.M.A.R.T. results, volume status, pool warnings, and recent system notifications. A degraded array, repeated drive errors, or abnormal latency deserves attention before performance tuning continues.
For persistent CPU or memory pressure, reduce unnecessary packages, limit container resources, or consider a model with a faster processor and more RAM. SSD caching may help repeated random access in suitable workloads, but it will not solve a saturated network connection, slow client disk, or a CPU-bound transcoding task. Hardware changes should follow measurement rather than replace it.
Use DiskStation Manager Resource Monitor during the next real slowdown and save your observations with the time, workload, and affected client. A short performance log can make recurring bottlenecks much easier to diagnose and gives you a reliable basis for adjusting schedules, services, network equipment, or NAS hardware.