GMS Taking Excessive Time to Process Event

Running Mobility CE 24.4 on Hyper V VM.  Getting Event Rate From GroupWise: There is a large number of requests coming from GroupWise   and   
Time to Process GroupWise Events: It is taking a long time to receive events from GroupWise.  I wonder if it may be related to disk size? VM is a self expanding disk that can go up to 1/4 TB in size. But it seems to be very tiny in terms of space taken up. Ext4 formated. Running on SLES 15.6. Any ideas?

  • 0  

    I would check the logs at both ends, GMS and the POA logs.  There might be some errors that are the issue, and taking care of them may well solve your problem.

    Also make sure both ends aren't resource constrained, such as swap space on either end being all used up.  CPU usage and load levels?
    As for that self expanding disk,  is that being pushed out steadily?  how much space % wise, is on that ext4 mount point? 

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    Nothing in logs. Used mcheck to reindex. Also converted to fixed disk. Fixed disk operation is thousand times faster. I'll see if that solves the issue and post back if not.

  • 0   in reply to 

    ah yes,  automatic isn't always as nice or good as we'd like it to be.  I recall Laura Chappell decreeing that Auto is Evil way back in IPX days in her '10 Truths of Network Troubleshooting'

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • Verified Answer

    +1   in reply to 

    Nothing in the logs does not mean much as we dont know the log level set, the SOAP settings on the POA done and what was looked for etc as this can make the difference in seeing hints or nothing.

    The best is to have these options in the POA startup file or set these options in the POA HTTP interface 

      --showreads
      --showupdates
      --showtrans
      --showsoaprequests
      --showsoapevents


    This with the log level in GMS on debug will give the info needed in the following logs


    the *.poa and *.soa logfiles of the POA
    the mobility-agent.log, groupwise-agent.log and suds.log of GMS

    Only with the above an knowing the time the event errors and large amount of GW requests are given you can analyze what happened and if this is a problem or maybe an action done causing this.
    In general the errors/warnings might be temporary when a user was added, a re-init was done or just a lot of users are synching at the same time, the values for the dashboard to report these are not configurable so some systems more busy then that can report this however this does not mean there is an actual problem, it just goes over the values set in the code so it reports this in the dashboard.

    Also testing from a user point of view and tracking the message flow can give more info, when a mail is sent how long does it actually take to get this on the users device. When longer then expected where is the delay, this with the logs and settings as above should be visible when tracking the test message.

    It can be disk related however i have not seen this until now as a major bottleneck for GMS yet.