| Applies to:
PcVue 10.0 sp1 update (10.0.16061), 10.0 sp2 update (10.0.26008), 11.0 update (11.0.06032.9123) and later. Related articles: KB495 |
||
|
|
||
| Summary:
There is a handle leak from VBA (whether you use VBA or not) which appears to occur when it detects more than 100 allocated threads. The solution is to create a pool of a pre-allocated threads. These pre-allocated threads are not detected by VBA. For example, if the project was using 450 threads and there was a pool 400 pre-allocated threads, VBA would only detect the remaining 50. |
||
|
|
||
| Details:
As the problem is with VBA, if you upgrade a project from an older PcVue version that didn’t include VBA, to newer one that does, a project that ran OK with the older version may exhibit problems when running on the newer version. This can happen on large projects and, in particular, on those projects using features that manage their threads outside of PcVue’s control. Third party DLL’s and the SCADA Basic instruction MULTIMEDIA are examples of this. The solution is to pre-allocate a pool of threads which is sufficiently sized to accomodate the threads used by the PcVue project in its normal operation. For example you could pre-allocate a pool of 400 threads. Only when more threads than this are required by PcVue, or threads are allocated outside of PcVue, would VBA detect them. However, if you put in a higher number it is not so much of an issue, just remember that the virtual memory for the threads get reserved (only ~1MB per Thread). If your PcVue is already near the 4GB limit it is better to set the lowest possible thread number. To pre-allocate a pool thread for PcVue you change the following in the SETTINGS.INI file in the ETC folder. [ThreadPool] Where n is the pre-allocated threads number (default of 0). When it is modified the message “Pool thread count = n” appears in the trace files (although it doesn’t appear in the event viewer). Since version 12 of PcVue, it exists also an equivalent setting for Web threads: Where n is the pre-allocated threads number (default of 0). So basically n web clients. The good value depends on the number of web licenses the customer has. When it is modified the message “Web pool thread count = n” appears in the trace files (although it doesn’t appear in the event viewer). You can also add a handle threshold limit which will produce a warning message in the Event Viewer. This is added to the SV32.INI file found in the BIN folder as follows. [HANDLELEAK] Where n is the warning limit (default of 60000). If the threshold is reached the following message appears in Event Viewer and is writen to the trace files. “The consumption of handle is too large, you have to relaunch the supervisor, HandleCount=xxxxx” A further message occurs if the thread count in the sv32.exe process, – 100, is greater than the number of threads in the pool. “There is a leak of handle, a workaround is to set the Count property of [ThreadPool] section in Settings.ini file in STU folder to xxx” |
||
|
|
||
| Further remarks:In 10.0 sp1 update and 10.0 sp2 update, you can check the number of threads in the pool using the audit files. The size of pool is “Free threads” + “Used threads”. For example:——Handles and threads in sv32 process—— Handles = 1584 Total Threads = 229 Free threads = 182 Used threads = 18 In 11.0 and later, you can check the number of threads in the pool using the audit files. The size of pool is “Free threads in pool” + “Used threads in pool”. For example: — Handles and threads in the Supervisor’s process (SV32.exe) — Why there is a difference between Total Threads and the number of thread in pool? |
||
|
|
||
|
Created on: 23 Oct 2014 Last update: 13 May 2024