InnoDB memory issue in MariaDB

Discussion:

(too old to reply)

issinoho

2020-10-09 16:57:48 UTC

FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)

Trying to install and run mariadb-5_5_64.zip (Berrymans)...

201009 17:48:24 InnoDB: The InnoDB memory heap is disabled
201009 17:48:24 InnoDB: Mutexes and rw_locks use VMS atomic functions
201009 17:48:24 InnoDB: Compressed tables use zlib 1.2.11
201009 17:48:27 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(136249344 bytes) failed; errno 65535
201009 17:48:27 InnoDB: Completed initialization of buffer pool
201009 17:48:27 InnoDB: Fatal error: cannot allocate memory for the buffer pool
201009 17:48:27 [ERROR] Plugin 'InnoDB' init function returned error.
201009 17:48:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
201009 17:48:27 [ERROR] Unknown/unsupported storage engine: InnoDB
201009 17:48:27 [ERROR] Aborting

So, is this a physical memory issue, a page/swap issue, or a database engine tuning issue?

TIA as always.

issinoho

2020-10-09 16:59:54 UTC

Permalink

Post by issinoho
FreeAXP 4.0.0.646
VSI AXPVMS VMS V8.4-2L1
VSI AXPVMS TCPIP V5.7-13ECO5F
VSI AXPVMS SSL111 V1.1-1GB
VSI AXPVMS CSWS V2.4-38D
PHP 7.2.29 (Berrymans)
Trying to install and run mariadb-5_5_64.zip (Berrymans)...
201009 17:48:24 InnoDB: The InnoDB memory heap is disabled
201009 17:48:24 InnoDB: Mutexes and rw_locks use VMS atomic functions
201009 17:48:24 InnoDB: Compressed tables use zlib 1.2.11
201009 17:48:27 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(136249344 bytes) failed; errno 65535
201009 17:48:27 InnoDB: Completed initialization of buffer pool
201009 17:48:27 InnoDB: Fatal error: cannot allocate memory for the buffer pool
201009 17:48:27 [ERROR] Plugin 'InnoDB' init function returned error.
201009 17:48:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
201009 17:48:27 [ERROR] Unknown/unsupported storage engine: InnoDB
201009 17:48:27 [ERROR] Aborting
So, is this a physical memory issue, a page/swap issue, or a database engine tuning issue?
TIA as always.

Additionally from the [.log]aria_log.00000001

%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

issinoho

2020-10-09 17:07:34 UTC

Permalink

Post by issinoho

Additionally from the [.log]aria_log.00000001
%TYPE-F-WRITEERR, error writing SYS$OUTPUT:.;
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded

Asked and answered... process limits of the account needed to be increased to match those of the MYSQL051_SRV account.

Arne Vajhøj

2020-10-09 17:16:04 UTC

Permalink

Readme.VMS in the dist contains suggestions for account quotas.

I used:

mod mysql$server
/fil=1000/bio=1000/dio=1000/ast=2500/enq=5000/byt=200000/pgfl=2000000

with 5.5.68 on Alpha.

Arne

Simon Clubley

2020-10-09 18:03:11 UTC

Permalink

Post by Arne Vajhøj
mod mysql$server
/fil=1000/bio=1000/dio=1000/ast=2500/enq=5000/byt=200000/pgfl=2000000
with 5.5.68 on Alpha.
Arne

I wonder if VSI should consider adding an optional thousands character
to numeric keyword values (ie: those keyword values defined as $NUMBER)
which could be silently stripped by the CLI parsing routines so the
value seen by programs is unchanged ?

The parsing routines could also issue a warning if the characters are
used in a $NUMBER value but are not placed at the expected points as
that could help catch when people type too few or too many digits for
a value.

It would make commands like the above more readable and less prone to
typing or reading errors.

For example:

mod mysql$server
/fil=1000/bio=1000/dio=1000/ast=2500/enq=5000/byt=200_000/pgfl=2_000_000

This would be fully backwards compatible with existing behaviour and
it would be up to the user whether they used a thousands character or not.

It would not change the value actually seen by the program the user is
running and the user could mix-and-match on the same command line as
I have done above.

This is for decimal numbers, but it may be worthwhile doing something
similar for octal and hex numbers as well.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

2020-10-09 19:32:36 UTC

Permalink

Post by Simon Clubley

Post by Arne Vajhøj
mod mysql$server
/fil=1000/bio=1000/dio=1000/ast=2500/enq=5000/byt=200000/pgfl=2000000
with 5.5.68 on Alpha.

I wonder if VSI should consider adding an optional thousands character
to numeric keyword values (ie: those keyword values defined as $NUMBER)
which could be silently stripped by the CLI parsing routines so the
value seen by programs is unchanged ?
The parsing routines could also issue a warning if the characters are
used in a $NUMBER value but are not placed at the expected points as
that could help catch when people type too few or too many digits for
a value.
It would make commands like the above more readable and less prone to
typing or reading errors.
mod mysql$server
/fil=1000/bio=1000/dio=1000/ast=2500/enq=5000/byt=200_000/pgfl=2_000_000
This would be fully backwards compatible with existing behaviour and
it would be up to the user whether they used a thousands character or not.

That, or K and M suffixes.

/byt=200K/pgfl=2M

Arne

Simon Clubley

2020-10-11 14:16:58 UTC

Permalink

Post by Arne Vajhøj

Post by Simon Clubley
I wonder if VSI should consider adding an optional thousands character
to numeric keyword values (ie: those keyword values defined as $NUMBER)
which could be silently stripped by the CLI parsing routines so the
value seen by programs is unchanged ?
The parsing routines could also issue a warning if the characters are
used in a $NUMBER value but are not placed at the expected points as
that could help catch when people type too few or too many digits for
a value.
It would make commands like the above more readable and less prone to
typing or reading errors.
mod mysql$server
/fil=1000/bio=1000/dio=1000/ast=2500/enq=5000/byt=200_000/pgfl=2_000_000
This would be fully backwards compatible with existing behaviour and
it would be up to the user whether they used a thousands character or not.

That, or K and M suffixes.
/byt=200K/pgfl=2M

But is that /pgfl=(2*1000*1000) or /pgfl=(2*1024*1024) ? :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Stephen Hoffman

2020-10-11 17:18:16 UTC

Permalink

Post by Simon Clubley

Post by Arne Vajhøj
That, or K and M suffixes.
/byt=200K/pgfl=2M

But is that /pgfl=(2*1000*1000) or /pgfl=(2*1024*1024) ? :-)

KB, KIB, MB, MIB, etc., were adopted ~20 years ago.

More than a little existing software around gets this wrong.

Given longstanding practice, I'd suggest developers use dice to select
whether to use the base-10 or the base-2 units.

This to ensure the continued quality of the existing displays and UIs.

But then we've also previously discussed DCL and the limitations of
compatibility, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Arne Vajhøj

2020-10-11 17:50:02 UTC

Permalink

Post by Simon Clubley

Post by Arne Vajhøj

That, or K and M suffixes.
/byt=200K/pgfl=2M

But is that /pgfl=(2*1000*1000) or /pgfl=(2*1024*1024) ? :-)

Add a note in the docs:

<note>
If it matters whether it is powers of 2 or powers of 10,
then increase the value with 50%. If you are just curious then
it is [insert chosen metric here].
</note>

:-)

Arne