Skip to main content
X
XIAOKE_WU3-Newcomer
3-Newcomer
October 14, 2025
Solved

DCS Server slow down when Kepware restart

  • October 14, 2025
  • 1 reply
  • 318 views

Our Kepware servers are reading around 100,000 tags from DCS server and forwarding to PI servers. We created one channel connecting to DCS server, and the minimum tag scan rate is 5000ms. The problem is when I meet some problems and reboot Kepware server, the DCS server will slow down for about 10 minutes after the Kepware instance running. We have already deleted 20,000 unnecessary tags, now the number is around 80,000, the problem remains. We also enabled “Read form cache” when start up, but it did not help. Would you please give suggestions on below points: 1. How to proof that it is not hardware issue which caused this problem? What should I check on DCS server side when Kepware server rebooted? For example, CPU load, network load, hard drive load, etc. By the way, the spec of DCS server is i7+32GB RAM+1TB SSD. 2. Is it possible to solve this problem just by changing settings or optimizing tag list in Kepware? So that we have less job to do and less arguments with other teams.

Best answer by pshashipreetham

Hi, 

 

This slowdown after restarting Kepware is a common behavior when handling large tag counts. When Kepware starts up, it must reinitialize all active tags, establish communications with the DCS, and populate the data cache. With 80,000–100,000 tags, this causes a short-term load spike on both Kepware and the DCS until the system stabilizes.

Here’s how to approach and optimize it:

  1. Validate Hardware and Resource Usage

    • Monitor CPU, memory, and network utilization on both the Kepware and DCS servers during startup.

    • A temporary surge (especially on the DCS communication port or CPU) indicates Kepware is re-polling all tags simultaneously.

  2. Reduce Startup Load in Kepware

    • In Project Properties → Advanced Tags, enable Load tags on demand instead of loading all tags at startup.

    • Increase the Scan Rate for non-critical tags to reduce initial network load.

    • Consider splitting tags across multiple channels to distribute polling.

  3. Cache and Update Behavior

    • The “Read from Cache on Startup” option doesn’t prevent Kepware from re-subscribing to all tags. It only helps with value initialization, not communication load.

    • If the DCS side is sensitive, consider staggering tag group activation using scripting or channel delays.

  4. DCS-Side Monitoring

    • Check the DCS for communication queue overload or tag buffer delays right after Kepware reconnects.

    • High CPU or queue buildup on the DCS confirms that the issue is from simultaneous re-requests.

  5. Practical Optimization

    • Review whether all 80,000 tags need to be continuously polled. Use conditional reads, event triggers, or on-demand tags where possible.

    • Upgrade Kepware to the latest version — newer builds handle large tag initialization more efficiently.

This problem typically isn’t hardware-related but rather a startup load issue. By optimizing tag distribution, scan rates, and load-on-demand behavior, you can significantly shorten recovery time after a restart.

 

Thanks,

1 reply

P
18-Opal
pshashipreetham18-OpalAnswer
18-Opal
October 16, 2025

Hi, 

 

This slowdown after restarting Kepware is a common behavior when handling large tag counts. When Kepware starts up, it must reinitialize all active tags, establish communications with the DCS, and populate the data cache. With 80,000–100,000 tags, this causes a short-term load spike on both Kepware and the DCS until the system stabilizes.

Here’s how to approach and optimize it:

  1. Validate Hardware and Resource Usage

    • Monitor CPU, memory, and network utilization on both the Kepware and DCS servers during startup.

    • A temporary surge (especially on the DCS communication port or CPU) indicates Kepware is re-polling all tags simultaneously.

  2. Reduce Startup Load in Kepware

    • In Project Properties → Advanced Tags, enable Load tags on demand instead of loading all tags at startup.

    • Increase the Scan Rate for non-critical tags to reduce initial network load.

    • Consider splitting tags across multiple channels to distribute polling.

  3. Cache and Update Behavior

    • The “Read from Cache on Startup” option doesn’t prevent Kepware from re-subscribing to all tags. It only helps with value initialization, not communication load.

    • If the DCS side is sensitive, consider staggering tag group activation using scripting or channel delays.

  4. DCS-Side Monitoring

    • Check the DCS for communication queue overload or tag buffer delays right after Kepware reconnects.

    • High CPU or queue buildup on the DCS confirms that the issue is from simultaneous re-requests.

  5. Practical Optimization

    • Review whether all 80,000 tags need to be continuously polled. Use conditional reads, event triggers, or on-demand tags where possible.

    • Upgrade Kepware to the latest version — newer builds handle large tag initialization more efficiently.

This problem typically isn’t hardware-related but rather a startup load issue. By optimizing tag distribution, scan rates, and load-on-demand behavior, you can significantly shorten recovery time after a restart.

 

Thanks,

Terms & ConditionsCookie settingsAccessibility statement