Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-3930

pmlogcheck takes more than one day to process the data

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Major Major
    • rhel-9.4
    • rhel-9.4
    • pcp
    • None
    • pcp-6.1.1-1.el9
    • Major
    • sst_pt_pcp
    • ssg_platform_tools
    • 3
    • QE ack, Dev ack
    • False
    • Hide

      None

      Show
      None
    • No
    • None
    • Pass
    • None
    • All
    • None

      What were you trying to do that didn't work?

      pmlogger_daily seems to take more than one full day while executing pmlogcheck on the PCP data. This makes 1 full CPU be used constantly.

      The directory of the data is 4GB big, trying to execute pmlogger_rewrite with the customer data, I can confirm at least more than 2 hours were required, I stopped after 2 hours of execution.

      Please provide the package NVR for which bug is seen:

      pcp-5.3.7-17.el8_8.x86_64

      How reproducible:

      Always on customer system

      Additional informations

      The customer is actually running RHEL8.4 latest PCP pcp-5.2.5-6.el8_4.

      With this release, pmlogger_daily executions start accumulating because of the way the pmlogger_daily.service is implemented (Type=oneshot + KillMode=none + TimeoutStartSec=1h), which causes numerous pmlogcheck processes to consume up to all the CPUs.

      Latest PCP for RHEL8.8. changed pmlogger_daily.service implementation, which now avoids accumulating processes, still it's not expected that pmlogcheck execution takes more than 1 hour, as suggested by the TimeoutStartSec=1h property in the service unit, which BTW does nothing at all since service has Type=exec).

            nathans@redhat.com Nathan Scott
            rhn-support-rmetrich Renaud Métrich
            pcp-maint pcp-maint
            Jan Kurik Jan Kurik
            Jacob Valdez Jacob Valdez
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: