Bug 1788597
| Summary: | Queries with entity_id IN ('1', '2', …, '70000') run much slower in MariaDB 10.3 than on MariaDB 10.1 | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Robert Scheck <redhat-bugzilla> | |
| Component: | mariadb | Assignee: | Michal Schorm <mschorm> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lukáš Zachar <lzachar> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 8.1 | CC: | apmukher, databases-maint, hhorak, jkejda, kwalker, ljavorsk, mschorm, robert.scheck | |
| Target Milestone: | rc | Keywords: | ZStream | |
| Target Release: | 8.1 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1899017 1899018 1899019 1899020 (view as bug list) | Environment: | ||
| Last Closed: | 2021-01-15 15:41:25 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1825061, 1856699, 1899017, 1899018, 1899019, 1899020 | |||
Cross-filed ticket 02554428 and 02554429 (two different customers) at the Red Hat customer portal. Hello, thanks for the thorough report. I will watch for the upstream release of 10.3.22 and I'll inform you once I'll get some results (wheter the version will fix the issue; fully or partially) or when I'd need more info. --- Current version of MariaDB in RHEL 8: 10.3.17 Latest version MariaDB released by upstream: 10.3.21 Version of MariaDB that should fix the issue: 10.3.22 Will MariaDB 10.3.22 land in z-Stream (8.1.z) or will we have to wait for RHEL 8.2? (In reply to Robert Scheck from comment #3) > Will MariaDB 10.3.22 land in z-Stream (8.1.z) or will we have to wait for RHEL 8.2? I can't tell. Usually, MariaDB updates in RHEL are security updates fixed by a rebase to the latest possible version. If we have fixes for another bugs, we try to add them to the update. I would probabbly like you to verify the update for this bug, before it will be released. In that case I'd prepade an unsupported testing build for you which should be same, or very simmilar, to what we plan to release. Currently, there are only 2 CVEs, with deadline in October 2020 and no urgency for the update. However nor planning nor decision has been yet made, so I can't tell. STATUS UPDATE: We have encountered issues with MariaDB 10.4.12 release. Until resolved, we stopped our work on MariaDB 10.3, which could possibly suffer with the same issue. Now the issues were resolved, we continue our work on the 10.3.22 release, so we can confirm or refute that the issue was resolved by upstream in that release. Scratch build of the mariadb-10.3.22 was successful, now we need to test if it doesn't break anything else, and if it's ready to be shipped. @Robert Do you have some "less complicated" reproducer for this bug, so I can try if it's fixed by the rebase? I've looked into the upstream's one and that doesn't look very pleasant. Lukas, unfortunately I'm not aware about more simple steps, given we discovered the bug in a quite complex scenario with a web shop software. I'm even not sure how to reproduce that ourself currently, given we had to switch the customer to MySQL 8 to get it flying. (In reply to Robert Scheck from comment #10) > Lukas, unfortunately I'm not aware about more simple steps, given we > discovered the bug in a quite complex scenario with a web shop software. We would be able to offer you an unsupported build, to verify it solves the issue for you. > I'm even not sure how to reproduce that ourself currently, given we had to switch the customer to MySQL 8 to get it flying. However I'm not sure if you are (still?) interested in it, since you built your solution on the MySQL instead. If you do not plan to get back to MariaDB - thus this BZ wouldn't have any priority to you anymore - you might want to close the customer ticket, leaving this BZ open for us to track it. Let me help to understand your current priority of this issue, so we can plan with it accordingly. Thank you We are still interested in a solution (as we also know some more to be affected systems which are still on RHEL 7 due to that), and we are still interested in switching the here affected customer back, but we can't do this easily in production. I guess we have to clone the production system in order to be really able to test that. So if you can provide an unsupported build where you believe it should address the issue, we'll take this road. Hello, I've prepared a repository for you with the new build I was talking about: http://people.redhat.com/mschorm/.rhbz-1788597/ You can use the repofile in there, placing it in "/etc/yum.repos.d/": http://people.redhat.com/mschorm/.rhbz-1788597/rhbz-1788597.repo After that, you should be able to install or update MariaDB to the new version by commands like "dnf install mariadb-server" or "dnf update" (if already installed). The "dnf module info mariadb" will still show the old packages in "Artifacts" section, but commands like "dnf module install mariadb" should install the new content. Let me know, if the build solves your issue. Sorry for the delay. Yes, it seems like 10.3.22 solves the issue for us. |
Description of problem: Queries with entity_id IN ('1', '2', …, '70000') run much slower in MariaDB 10.3 than on MariaDB 10.1, which makes MariaDB 10.3 (as shipped in RHEL 8.1 including all updates) just unusable for Magento 2.3 when running its indexer (the Magento indexer needs ~ 60 mins with MariaDB 10.3 vs. 1 Min at MySQL 8.0). Known upstream issues: - https://jira.mariadb.org/browse/MDEV-20871 - https://jira.mariadb.org/browse/MDEV-20900 See also: - https://github.com/magento/magento2/issues/25199 - https://github.com/magento/magento2/pull/25212 Version-Release number of selected component (if applicable): mariadb-server-10.3.17-1.module+el8.1.0+3974+90eded84 How reproducible: See upstream issue, alternatively the Magento 2 indexer works also as a (quite complicated) reproducer. Actual results: Queries with entity_id IN ('1', '2', …, '70000') run much slower in MariaDB 10.3 than on MariaDB 10.1. Expected results: Queries with entity_id IN ('1', '2', …, '70000') run with same speed in MariaDB 10.3 like on MariaDB 10.1 or MySQL 8.0, e.g. by rebase to current MariaDB 10.3 version (or backport of the fix).