DX Unified Infrastructure Management

 View Only
  • 1.  The wasp probe lately are consumed the memory of the server totally

    Posted Apr 27, 2018 07:46 AM

    Hi everyone.

     

    The wasp probe lately are consumed the memory of the server totally

    waspprobeconsume

    do you know for that this situation?

     

    My configuration is:

    UMP ver 8.51

    -Xmx10240m

    -Xms512m

    Currently the consume of the memory is 11.035 mb, all memory assign to the probe. Only 8 users connected 

    UIM ver 851 SP1

     

     

    Other question: How can I finish the sessions with time expired in UMP?

    get_sessions_UMP



  • 2.  Re: The wasp probe lately are consumed the memory of the server totally

    Posted Apr 27, 2018 09:02 AM

    Hello Miller!

     

    What was the average memory used in the last weeks?

     

    The memory used is not just based on the number of users connected.

     

    Do you have lot of custom dashboards in your environment .
    How many active alarms in the environment
    What type of dashboards are in your environment i.e alarm/ QOS type etc
    Is the database maintenence done regularly like defragmentation etc

     

    Please try:

     

    Go to UMP
    Control panel
    Server administration
    Reindex all search indexes

     

    Then:

     

    1- deactivate wasp;
    2- delete the content of \wasp\work folder
    3- clear browser cache from beginning of time
    4- Activate wasp

     

     

    Kind Regards,

     

    Alex Yasuda
    Sr. Support Engineer



  • 3.  Re: The wasp probe lately are consumed the memory of the server totally

    Posted May 06, 2018 10:55 PM

    Hi Alex.

     

    I will coordinate with the customer this activity. Because this procedure caused unavailability in UMP Portal
    Thank for you answer and I inform you when apply this procedure.

     

    M.E



  • 4.  Re: The wasp probe lately are consumed the memory of the server totally

    Broadcom Employee
    Posted May 04, 2018 10:44 AM

    Hi @Miller Grisepe Echagarreta Parra, did Alex's suggestion help with your problem?



  • 5.  Re: The wasp probe lately are consumed the memory of the server totally

    Posted May 04, 2018 02:31 PM

    Is your question why the process is using roughly 11Gb of memory when you specified the max JVM memory to be 10GB or are you surprised that wasp used all the memory you allowed it to?

     

    The first question is that the 10GB you indicated as the max is just the limit on the space that java does generic memory allocations out of. It is not a limit on the whole thing though all the rest of the memory that a Java VM is going to use is pretty static and so you'll see the -Xmx10240m exceeded but that will generally remain by a fixed amount. I wouldn't e surprised to see what you have here.

     

    Regarding the second version of hte question, of the operations of taking memory, releasing memory, and determining what memory can be released, you get the most bang for the buck allocating free memory for a new demand. So, your typical JVM, if not otherwise affected by calls to the garbage collection routines, will fairly quickly allocate/use all the memory you allocate to it. It'll still be free memory within the JVM so it can be reused later but to the OS it will be allocated to the process. This is normal and it's done for performance reasons. The last thing you want to do is to run garbage collection to free up space for a new variable - better to ask the OS for a little bit more previously unused memory. 

     

    -Garin



  • 6.  Re: The wasp probe lately are consumed the memory of the server totally

    Posted May 10, 2018 03:14 PM

    Miller,

     

    For the second question

    The session time out is located in the portal-ext.properties file in the
    C:\Program Files (x86)\Nimsoft\probes\service\wasp\webapps\ROOT\WEB-INF\classes directory
     
    # Time out after five minutes, but automatically request an extension after one
    # minute as long as the user is currently browsing to a portal page. The
    # timeout is really configured in ../web.xml.
     
    session.timeout=5
    session.timeout.warning=1
    session.timeout.auto.extend=true