CA Service Management

  • 1.  CA Service Catalog Memory Leak

    Posted Jul 21, 2017 10:42 AM

    I've recently been tasked to performance test our CA Service Catalog (SLCM) instance, namely for capacity testing and growth.

    Our SLCM QA Server is a VM with a Intel Xeon E5-2680 2.8GHz CPU with 4 processors, along with 6GB RAM, running Windows Server 2008 R2 x64.

     

    Using 3rd party tools, I've been performance testing the application starting the test with 10 users and incrementing the users by 10 every 10 minutes to a maximum of 30 users running concurrently, which after 40 minutes of starting the test, causes the CA Service Catalog application to crash, crashing at around 01H04min.

     

    When we start the application service, using task manager, I've noted that the process only consumes about +/- 300MB of RAM, but once we start performance testing, the RAM usage fluctuates between 1.3GB and 1.57GB of RAM, to which minimal amounts of RAM are released.

     

    Once the test has concluded though, we haven't seen the memory usage reduce to the range of 300MB. Could there possibly be a memory leak issue with CA Service Catalog or could it be just with our instance? Could other users test out this theory because I need to determine if there's a problem with CA Service Catalog, or our instance or if we need to throw more system resources into the server.

     

    Disclaimer: the reason why the pass rate spiked just before 01H20 was due to our virtual users existing the system.

     



  • 2.  Re: CA Service Catalog Memory Leak

    Broadcom Employee
    Posted Jul 21, 2017 11:05 AM

    Hello,

     

    Can you clarify the exact version being used with CA Service Catalog (specify the cumulative and incremental level)? My question is because there are some fixes provided on top of incremental 2 that fixes some performance issues. Also, those fixes are already included in 14.1 CP4.

     

    Regards,

    Pablo



  • 3.  Re: CA Service Catalog Memory Leak

    Posted Jul 21, 2017 11:31 AM

    Hi Pablo,

     

    We're running SLCM 14.1.02 Incremental 2.

     

    Thanks for your suggestion. I'll download and install the latest patches and see if that averts the issue.

     

    I'll revert back by Wednesday 26/07/2017 12H00 UTC+2

     

    Kind Regards,

    Mo



  • 4.  Re: CA Service Catalog Memory Leak

    Broadcom Employee
    Posted Jul 21, 2017 11:31 AM

    Hi,

    as well as ensuring you've got the appropriate patches, what you're describing is the Java process hitting the memory limit configured for CA Service Catalog, and then having to spend time cleaning up the memory pools to continue. It won't empty these caches unless it has to, however, which is why you don't then see it go back to the original low usage state.

     

    You'll find recommendations for better performance settings here, but they will to some extent depend on how much memory is available at the OS level - 6GB isn't a lot for a server these days:

     

    Performance Tuning Parameters 

     

    regards

    Iain



  • 5.  Re: CA Service Catalog Memory Leak

    Posted Jul 21, 2017 12:01 PM

    Hi Iain,

     

    Thanks for the explanation behind the Java process.

     

    Could you recommend the memory capacity I should have installed on the server? At the moment on our production server, we see about +/- 700 service requests submitted between 07H00 and 17H00 with majority being between 09H00 and 15H00. (Our Catalog application usage is still growing)

     

    oyapa01, I can't seem to find the CP4 when I browse the CA support site, as per screenshot below. Any advice?



  • 6.  Re: CA Service Catalog Memory Leak

    Broadcom Employee
    Posted Jul 21, 2017 12:18 PM

    Hi Mo,

     

    Please try the following link:

     

    CA Service Catalog iCan View Solutions & Patches - CA Technologies 

     

    RO96941 is the one you need. Here more info about this new release:

     

    CA Service Management Release 14.1.04 - CA Service Management - 14.1 - CA Technologies Documentation 

     

     

    Regards,

    Pablo