Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-33079

--source include/wait_condition.inc very slow in main.show_explain

Details

    • Bug
    • Status: Stalled (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • 11.4
    • None
    • None
    • macOS 13.6.3 aarch64 (apple silicon)

    Description

      Affects only macOS afaik. main.show_explain includes wait_condition.inc whenever it needs to wait for a bit before checking a condition. On linux, this wait is very short but on macOS (as verified with --mark-progress), it's quite lengthy, sometimes 10 or more seconds. Why is this? Interestingly, the $wait_condition variable isn't set before sourcing wait_condition.inc; setting that variable is a common pattern in other tests that use wait_condition.inc. Perhaps that usage is incorrect and on Linux it just happens to be enough of a delay for the desired event to occur, but I'm speculating.

      Attachments

        Issue Links

          Activity

            psergei Sergei Petrunia added a comment - - edited

            there is

            let $wait_condition= select State='show_explain_trap' from information_schema.processlist where id=$thr2;
            

            at the start of show_explain.test before any "invocation" of wait_condition.inc, isn't it?

            psergei Sergei Petrunia added a comment - - edited there is let $wait_condition= select State='show_explain_trap' from information_schema.processlist where id=$thr2; at the start of show_explain.test before any "invocation" of wait_condition.inc , isn't it?
            Gosselin Dave Gosselin added a comment -

            This isn't a test issue after all, but rather show explain for takes nearly one second on macOS when the same is nearly instantaneous on Linux.

            Gosselin Dave Gosselin added a comment - This isn't a test issue after all, but rather show explain for takes nearly one second on macOS when the same is nearly instantaneous on Linux.
            Gosselin Dave Gosselin added a comment -

            The use of APCs causes at least part of the slowdown observed on macOS. When waiting for all APC calls to be serviced, we invoke my_sleep from dbug_serve_apcs. This sleep is implemented as a call to select() with a valid timeval struct. However on macOS, this select takes longer to return than on Linux. Experimenting with this mechanism leads to show explain for running essentially in the same time as on Linux. However, as far as the test is concerned, it still runs in about 60s on mac (after applying improvements to the waiting mechanism) when on linux it completes in about 5s.
            Rather than take a polled approach, we could convert dbug_serve_apcs to use a condition variable as that is supported on both linux and mac.
            As an aside, I noticed that my_sleep is supposed to be passed a value in microseconds, but I surmise from usage in our codebase that many callers treat it like it's in milliseconds. I wonder if there are latent bugs as a result.
            For now, I'm setting this ticket aside and lowering the priority.

            Gosselin Dave Gosselin added a comment - The use of APCs causes at least part of the slowdown observed on macOS. When waiting for all APC calls to be serviced, we invoke my_sleep from dbug_serve_apcs. This sleep is implemented as a call to select() with a valid timeval struct. However on macOS, this select takes longer to return than on Linux. Experimenting with this mechanism leads to show explain for running essentially in the same time as on Linux. However, as far as the test is concerned, it still runs in about 60s on mac (after applying improvements to the waiting mechanism) when on linux it completes in about 5s. Rather than take a polled approach, we could convert dbug_serve_apcs to use a condition variable as that is supported on both linux and mac. As an aside, I noticed that my_sleep is supposed to be passed a value in microseconds, but I surmise from usage in our codebase that many callers treat it like it's in milliseconds. I wonder if there are latent bugs as a result. For now, I'm setting this ticket aside and lowering the priority.

            People

              Gosselin Dave Gosselin
              Gosselin Dave Gosselin
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.