Hi Ber Pollisco ,

TC is a heavy protocol that needs a lot of CPU resources. It is always a good habit to monitor the resource consumption of your LGs: CPU, Free Memory, Free Disk Space and Disk Usage.

I guess that you overloaded your LG. You might find in your test results in LRE, at the message tab some messages that might indicate overloaded CPU. But when you are short on memory and LG starts swapping, CPU might not be that high.

Note that an LG should not consume more than 60% of CPU capacity.

Hi JHF Remmelzwaal ,

Thank you for this response. Tried to update our LG to have 48 vCPU and 384 Memory and still it failed to execute more than 95 virtual user.

Here is the graph: 

CPU is the orange peak at the end. That occurred after having an error like what I've mentioned. Should I continue raising up the CPU and Memory of my load generator? 

How many users did you test, again 100? You need to build up expectations. Run with 10, 20, 30, 50, 70, 90, ... users and see what happens with response times, number of transactions, system resources etc. Based on those type of results you might identify what is causing the issue.

Are the numbers inline with your expectations? Have a look to chrome.exe when you run locally+manually and see how much private memory is used: do some math.

You might have a look to this old post. It might be still valid. Truclient Chomrium Vusers are getting stuck in init state

I did now saw this error in the last view years but I know that some programs play with the SharedSection in an unexpected way.

We have an older Load Generator with specs similar to yours and our main constraint is disk utilization.  I would recommend you monitor disk in addition to CPU and memory.