Use Task Manager to identify sustained processing, memory or disk pressure during the actual trading workload. Reduce unnecessary chart/history work one change at a time. High total CPU can matter, but a universal 70–80% threshold or a process-priority change is not a verified cure for Rithmic disconnects.
Educational software guidance. Trading involves risk. Read the financial and information disclaimers.
Inspect the workload
Open Task Manager with Ctrl+Shift+Esc. Inspect Processes for CPU/memory usage and Performance for CPU, memory, disk and network behavior. Microsoft describes these monitoring tools. A brief snapshot taken while idle does not diagnose a burst at the market open.
Record platform version, active workspaces, chart/indicator count, instruments and requested history. One saturated execution thread can be a problem even when the overall CPU percentage is modest. Memory pressure and disk paging can resemble a CPU problem.
Reduce work deliberately
| Change to evaluate | What to observe |
|---|---|
| Remove unused charts/indicators | Application response and CPU under comparable data load |
| Reduce initial history range | Startup load and completeness of the required analysis |
| Reduce unnecessary subscriptions | Data-processing volume and missing required instruments |
| Adjust supported display refresh/aggregation | Resource savings versus lost analysis detail |
| Schedule heavy background work | Contention without weakening security or recovery |
Do not disable a strategy's needed data or change intrabar behavior merely to make a usage graph lower. Bookmap warns that aggregation can hinder MBO functionality; ATAS also requires matching host/client settings for its plugin route.
Verify the improvement
Repeat the same workload and compare resource pressure, quote age, application responsiveness and logged disconnects. Revert an ineffective change. Preserve diagnostic logs before updates. An upgraded VPS helps only if the relevant bottleneck is improved; extra account rows alone are not a resource-sizing model.
No priority, affinity, firewall or power-policy change was performed on this VPS. A process-priority change should follow a diagnosed need and platform-supported guidance.
Common questions
Should I always set High process priority?
No. Diagnose the bottleneck and follow platform-supported guidance.
Does low total CPU rule out a processing bottleneck?
No. One busy thread, memory pressure or disk activity can still matter.
Should I remove all order-flow indicators?
Remove only unnecessary work and check whether the strategy still receives its required data.
Was a loaded-platform benchmark run here?
No. This is a measured-diagnosis procedure, not a claimed performance test.