[
https://issues.apache.org/jira/browse/IGNITE-19412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-19412:
-----------------------------------------
Assignee: Konstantin Orlov
> Potential memory leak in MailboxRegistryImpl under intensive SQL load
> ---------------------------------------------------------------------
>
> Key: IGNITE-19412
> URL: https://issues.apache.org/jira/browse/IGNITE-19412
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Affects Versions: 3.0.0-beta1
> Reporter: Andrey Khitrin
> Assignee: Konstantin Orlov
> Priority: Major
> Labels: ignite-3, sql
> Attachments: Screenshot_20230503_172458.png, ddl-ignite3.sql,
> java_pid4802_Leak_Suspects.zip
>
>
> 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)
