• State Suggested Answer
  • Replies replies
    7
  • Answers answer
    1
  • Subscribers subscribers
    18
  • Views views
    402
  • Users 0 members are here

2 gwpoa running in the same server with just 1 PO - GW24.1 on OES2018-3

calil

We are having hgh cpu utilization and I could see tat are two gwpoa running with deifferent PID´s

Parents

  • Suggested Answer

    0  

    as per David, two instances is normal.

    as for high CPU, there are a number of things that it could be that I've seen

    - Tight on memory, so it is busy swapping out all the time.  GroupWise really benefits by having sufficient memory to cache the active database files.  I watch the swap levels, and if swap is being fully consumed, it likely benefits from adding memory to this system.  If it takes a few weeks to use it up without the high cpu, then we can play with swappiness some.   Details assuming on SLES/OES based on the PID reference, but version would still be a good reference here. 

    - Drive access issues. I've seen where an over busy SAN (DR replication issue) can show as high CPU.  Make sure your storage system is healthy, and that you generally have over 10% free on all mount points.

    - GWChecks (schedule or not GW maintenance) can really push a system. You can see if any are running on the POA http status page, and I have my recommended GW practices page you can check out as well.  After the above-mentioned SAN issues, the bigger GWChecks (Full Contents Analyze/Fix) would run way longer than their normal weekend runs.

    ________________________

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

Reply

  • Suggested Answer

    0  

    as per David, two instances is normal.

    as for high CPU, there are a number of things that it could be that I've seen

    - Tight on memory, so it is busy swapping out all the time.  GroupWise really benefits by having sufficient memory to cache the active database files.  I watch the swap levels, and if swap is being fully consumed, it likely benefits from adding memory to this system.  If it takes a few weeks to use it up without the high cpu, then we can play with swappiness some.   Details assuming on SLES/OES based on the PID reference, but version would still be a good reference here. 

    - Drive access issues. I've seen where an over busy SAN (DR replication issue) can show as high CPU.  Make sure your storage system is healthy, and that you generally have over 10% free on all mount points.

    - GWChecks (schedule or not GW maintenance) can really push a system. You can see if any are running on the POA http status page, and I have my recommended GW practices page you can check out as well.  After the above-mentioned SAN issues, the bigger GWChecks (Full Contents Analyze/Fix) would run way longer than their normal weekend runs.

    ________________________

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

Children

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.