Memory increase after Update from 1.2 to 1.4.199

[Philipp]

Hi,

we use the H2 Database in our software as embedded solution. After the update from 1.2 to 1.4.199, the memory is increasing to factor ~2. In numbers: from HeapSpace use ~7,9GB to ~14,9GB.
I have searched in this forum and with google, but i don't found any solution for our problem here.
We load our data from MySQL / MSSQL to the embedded H2 with Hibernate. We talk about 20millions Rows with 13 columns. (datetime, 2x numeric, 2x varchar(64), 5x float, 3x tinyint) (6x index) (MSSQL Table Size: 2.6GB)
This is 1 table in our system (the biggest one). We use currently 19 tables on the whole java instance. In sum we talk about a database size with 24millionsrows.

I had tried differnt parameters in the url:
This is our standard url: jdbc:h2:mem:accountvalues;DB_CLOSE_DELAY=-1;
Now the new tested urls:
jdbc:h2:nioMemFS:" + idProject + ";DB_CLOSE_DELAY=-1;  -> Database connection closed during loading
jdbc:h2:memLZF:" + idProject + ";DB_CLOSE_DELAY=-1; -> Many many SQL Errors
jdbc:h2:memFS:" + idProject + ";DB_CLOSE_DELAY=-1; -> To much Memory (> 25GB Heap space)
jdbc:h2:nioMemLZF:" + idProject + ";DB_CLOSE_DELAY=-1; -> Database connection closed during loading
jdbc:h2:mem:accountvalues;DB_CLOSE_DELAY=-1;MV_STORE=false; -> Load very slow with no changes
jdbc:h2:mem:accountvalues;DB_CLOSE_DELAY=-1;NO_UPGRADE=TRUE; -> No changes on memory

I have checked open commits with "SELECT * FROM INFORMATION_SCHEMA.SESSIONS;" and only 1 connection is opened with State "Waiting". There are no open commits or something like this.
Here are the Settings of the H2:

Is there a known problem or exist other parameters which we can test?

Thanks,
Phill

PS: the H2 Settings values:

DB_CLOSE_DELAY:  -1
CREATE_BUILD:  199
info.BUILD_ID:  199
info.VERSION_MAJOR:  1
info.VERSION_MINOR:  4
info.VERSION:  1.4.199 (2019-03-13)
property.java.runtime.version:  1.8.0_121-b13
property.java.vm.name:  Java HotSpot(TM) 64-Bit Server VM
property.java.vendor:  Oracle Corporation
property.os.name:  Windows 10
property.os.arch:  amd64
property.os.version:  10.0
property.sun.os.patch.level: 
property.file.separator:  \
property.path.separator:  ;
property.line.separator:  "
"
property.user.country:  DE
property.user.language:  de
property.user.variant: 
property.file.encoding:  Cp1252
EXCLUSIVE:  FALSE
MODE:  REGULAR
MULTI_THREADED:  1
QUERY_TIMEOUT:  0
RETENTION_TIME:  0
LOG:  2
ALIAS_COLUMN_NAME:  false
ANALYZE_AUTO:  2000
ANALYZE_SAMPLE:  10000
CASE_INSENSITIVE_IDENTIFIERS:  false
COMPRESS:  false
DATABASE_TO_LOWER:  false
DATABASE_TO_UPPER:  true
DB_CLOSE_ON_EXIT:  true
DEFAULT_CONNECTION:  false
DEFAULT_ESCAPE:  \
DEFAULT_TABLE_ENGINE: 
DEFRAG_ALWAYS:  false
DROP_RESTRICT:  true
EARLY_FILTER:  false
ESTIMATED_FUNCTION_TABLE_ROWS:  1000
FUNCTIONS_IN_SCHEMA:  true
LOB_TIMEOUT:  300000
MAX_COMPACT_COUNT:  2147483647
MAX_COMPACT_TIME:  200
MAX_QUERY_TIMEOUT:  0
MV_STORE:  true
OPTIMIZE_DISTINCT:  true
OPTIMIZE_EVALUATABLE_SUBQUERIES:  true
OPTIMIZE_INSERT_FROM_SELECT:  true
OPTIMIZE_IN_LIST:  true
OPTIMIZE_IN_SELECT:  true
OPTIMIZE_OR:  true
OPTIMIZE_TWO_EQUALS:  true
OPTIMIZE_UPDATE:  true
PAGE_STORE_INTERNAL_COUNT:  false
PAGE_STORE_MAX_GROWTH:  131072
PAGE_STORE_TRIM:  true
QUERY_CACHE_SIZE:  8
RECOMPILE_ALWAYS:  false
RECONNECT_CHECK_DELAY:  200
REUSE_SPACE:  true
SHARE_LINKED_CONNECTIONS:  true
STANDARD_DROP_TABLE_RESTRICT:  false

[Andrei Tokar]

It has been a change of the underlying storage engine used by default. You can try MV_STORE=false to stay with old pgstore.

[Philipp]

Hello,

i had tried this parameter, but it's loading very slow and have no really effect for the memory.

Exist other possibilities which can i try to do?

We are trying to minimize our data in the H2 InMemory, but there are limits.

Thanks,

Phill