RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1788597 - Queries with entity_id IN ('1', '2', …, '70000') run much slower in MariaDB 10.3 than on MariaDB 10.1
Summary: Queries with entity_id IN ('1', '2', …, '70000') run much slower in MariaDB 1...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: mariadb
Version: 8.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.1
Assignee: Michal Schorm
QA Contact: Lukáš Zachar
URL:
Whiteboard:
Depends On:
Blocks: 1825061 1856699 1899017 1899018 1899019 1899020
TreeView+ depends on / blocked
 
Reported: 2020-01-07 15:21 UTC by Robert Scheck
Modified: 2024-03-25 15:36 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1899017 1899018 1899019 1899020 (view as bug list)
Environment:
Last Closed: 2021-01-15 15:41:25 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Robert Scheck 2020-01-07 15:21:30 UTC 
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).
Comment 1 Robert Scheck 2020-01-07 15:26:45 UTC 
Cross-filed ticket 02554428 and 02554429 (two different customers) at the Red Hat customer portal.
Comment 2 Michal Schorm 2020-01-08 14:49:35 UTC 
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
Comment 3 Robert Scheck 2020-01-08 14:58:25 UTC 
Will MariaDB 10.3.22 land in z-Stream (8.1.z) or will we have to wait for RHEL 8.2?
Comment 4 Michal Schorm 2020-01-08 15:26:18 UTC 
(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.
Comment 6 Michal Schorm 2020-03-30 14:56:17 UTC 
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.
Comment 9 Lukas Javorsky 2020-04-03 12:45:45 UTC 
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.
Comment 10 Robert Scheck 2020-04-03 14:52:21 UTC 
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.
Comment 11 Michal Schorm 2020-04-08 12:42:17 UTC 
(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
Comment 12 Robert Scheck 2020-04-08 13:06:07 UTC 
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.
Comment 13 Michal Schorm 2020-04-21 13:12:08 UTC 
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.
Comment 15 Robert Scheck 2020-07-15 11:25:13 UTC 
Sorry for the delay. Yes, it seems like 10.3.22 solves the issue for us.
Note You need to log in before you can comment on or make changes to this bug.