Forum Discussion

cshukusky's avatar
cshukusky
Contributor
7 years ago

Memory Usage of TestComplete Plugin in Jenkins

I have a Jenkins master running on a windows 10 PC with the latest version of 64 bit java 1.8.151.  I have allowed it 6GB max heap space.  I have a slave running through java web start, same version of OS and java, and I have allowed 3GB max heap space.

 

I have a rather large test (~10,000 test cases, ~24 hour run time), which I run on the slave.  Jenkins generally seems capable of running at least a few of the tests on various slaves at the same time, until one of them finishes and is ready to send the results log back to the master.  The log folder on the slave PC is about 700MB.  When it attempts to return that to the master through Jenkins, java runs out of memory (java memory usage in task manager goes from around 1GB to the max 6GB).

 

Has anybody else had similar issues with such large spikes in memory usage for a log?  Any suggestions on how to resolve it, other than making smaller tests (I will do that if I have to, but organizing the very large number of test cases into smaller pieces is rather ugly)? Or is this just java being java?  Thanks in advance.

9 Replies

Sort By
  • Marsha_R's avatar
    Marsha_R
    Champion Level 3
    7 years ago

    There are things you can do to make the log smaller if you want to try that. 

     

    Make sure you aren't saving screenshots for everything and you can also turn off the event logging (all the little messages about this button was clicked etc.) and that will save a bunch of space.

    • cshukusky's avatar
      cshukusky
      Contributor
      7 years ago

      I do have visualizer turned off.  And there were only 8 errors, so there were only a few images for those errors.  As for the events, I had considered that, but I hesitate to remove useful debug info like that should something go wrong.  In conjunction with testing a large number of individual test cases we are also using the long test to test performance and memory leaks over time, so having the events in the log has proved useful, and given the runtime of the test, we don't necessarily have the resources to simply turn the events back on and rerun when something does fail.  And only saving the last x number of events before an error hasn't always proved sufficient either.

       

      But thank you for the response.

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        7 years ago
        cshukusky wrote:

        As for the events, I had considered that, but I hesitate to remove useful debug info like that should something go wrong.  I

        This is why the following option exists under Tools -> Current Project Properties -> Playback:


         

        Basically, what this does is will "lock" the events on the project so they won't write out to the log for every click or keystroke.  However, whenever a warning or error is logged, the last X number of events preceeding that warning or error are logged.  This provides the desired debug info to determine why the warning/error appeared. If there are no warnings or errors, there are no events in the log.