You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Andrey Khitrin (Jira)" <ji...@apache.org> on 2023/05/04 12:49:00 UTC
[jira] [Created] (IGNITE-19419) Corrupted LogStorage under intensive SQL load
Andrey Khitrin created IGNITE-19419:
---------------------------------------
Summary: Corrupted LogStorage under intensive SQL load
Key: IGNITE-19419
URL: https://issues.apache.org/jira/browse/IGNITE-19419
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 (commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).
Ignite3 was running with -Xmx6G -Xms6G memory limit. After some time it has reached memory limits and failed due to OutOfMemoryError. A heap dump was generated on failure. I can't attach this dump due to its size, but I've opened it in MAT and created a report (see zip file attached).
The report says that most of the retained heap (almost 5G) is occupied by a single instance of o.a.i.internal.sql.engine.exec.MailboxRegistryImpl class (see image attached).
{*}Hypothesis{*}: on an intense load, MailboxRegistryImpl creates a lot of lambda expressions. This happens faster than they're being utilized. With limited memory size, it could lead to OOM at some moment.
Benchmark is quite trivial by mechanics:
1. Create a table structure (see DDL file attached)
2. Fill tables with randomized data (several tens of thousands rows is enough)
3. Run select queries in a loop (actually, it wouldn't happen; OOM was raised on data insertion).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)