Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The memory usage of OrientDB with empty data has increased to 1.4G #10042

Open
kxc1573 opened this issue Dec 4, 2023 · 1 comment
Open

The memory usage of OrientDB with empty data has increased to 1.4G #10042

kxc1573 opened this issue Dec 4, 2023 · 1 comment
Milestone

Comments

@kxc1573
Copy link

kxc1573 commented Dec 4, 2023

OrientDB Version: 3.2.20

Java Version: openjdk version "17.0.7"

OS: Linux docker (x86 + s390x)

Expected behavior

When I enable Orientdb in Docker, it occupies approximately 900M of memory.
If I don't have any other actions, it should always remain at this value

Actual behavior

The next day, I found that it occupied 1.4GB of memory and remained stable at this value.
During this period, I did not put data into Orientdb because it was only one of our components, and I was testing other components.

Steps to reproduce

just run it up inner docker

Other info

image image

And I get some error message in the log:

Nov 29 07:06:58 b25578adf298 server.sh[26]: 2023-11-29 07:06:58:066 INFO  Databases directory: /orientdb/databases [OServer]
Nov 29 07:06:58 b25578adf298 server.sh[26]: 2023-11-29 07:06:58:202 INFO  Page size for WAL located in /orientdb/databases/OSystem is set to 4096 bytes. [CASDiskWriteAheadLog]
Nov 29 07:06:58 b25578adf298 server.sh[26]: 2023-11-29 07:06:58:406 WARNI Error detecting block size ignoring [ONative]
Nov 29 07:06:58 b25578adf298 server.sh[26]: java.lang.RuntimeException: native error calling fstat: Bad file descriptor -1
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at jnr.posix.util.DefaultPOSIXHandler.error(DefaultPOSIXHandler.java:24)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at jnr.posix.LinuxPOSIX.fstat(LinuxPOSIX.java:92)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at jnr.posix.LinuxPOSIX.fstat(LinuxPOSIX.java:124)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at jnr.posix.CheckedPOSIX.fstat(CheckedPOSIX.java:135)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at jnr.posix.LazyPOSIX.fstat(LazyPOSIX.java:132)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.common.jnr.ONative.blockSize(ONative.java:557)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.common.io.OIOUtils.calculateBlockSize(OIOUtils.java:433)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.storage.cache.local.doublewritelog.DoubleWriteLogGL.open(DoubleWriteLogGL.java:124)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.storage.cache.local.OWOWCache.loadRegisteredFiles(OWOWCache.java:476)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.storage.disk.OLocalPaginatedStorage.initWalAndDiskCache(OLocalPaginatedStorage.java:812)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.open(OAbstractPaginatedStorage.java:516)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.db.OrientDBEmbedded.getAndOpenStorage(OrientDBEmbedded.java:594)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.db.OrientDBEmbedded.openNoAuthorization(OrientDBEmbedded.java:523)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.db.OrientDBEmbedded.openNoAuthorization(OrientDBEmbedded.java:84)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.db.OSystemDatabase.openSystemDatabase(OSystemDatabase.java:86)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.db.OSystemDatabase.checkServerId(OSystemDatabase.java:165)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.core.db.OSystemDatabase.init(OSystemDatabase.java:153)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.server.OServer.initSystemDatabase(OServer.java:1147)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.server.OServer.activate(OServer.java:430)
Nov 29 07:06:58 b25578adf298 server.sh[26]:         at com.orientechnologies.orient.server.OServerMain$1.run(OServerMain.java:49)
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:58:411 INFO  DWL:OSystem: block size = 4096 bytes, maximum segment size = 8865 MB [DoubleWriteLogGL]
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:59:123 INFO  Storage 'plocal:/orientdb/databases/OSystem' is opened under OrientDB distribution : 3.2.20 (build 209ef77f546ea87fd356b81b4aa6f7>
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:59:592 INFO  Listening binary connections on 0.0.0.0:2424 (protocol v.38, socket=default) [OServerNetworkListener]
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:59:605 INFO  Listening http connections on 0.0.0.0:2480 (protocol v.10, socket=default) [OServerNetworkListener]
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:59:612 INFO  Installing dynamic plugin 'orientdb-etl-3.2.20.jar'... [OServerPluginManager]
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:59:620 INFO  Installing dynamic plugin 'orientdb-studio-3.2.20.zip'... [OServerPluginManager]
Nov 29 07:06:59 b25578adf298 server.sh[26]: 2023-11-29 07:06:59:622 INFO  [OVariableParser.resolveVariables] Property not found: distributed [orientechnologies]

But strangely enough, it doesn't seem to affect the read and write operations of my existing code

@tglman tglman added this to the 3.2.x milestone Jan 8, 2024
@tglman
Copy link
Member

tglman commented Jan 8, 2024

Hi,

Thanks to report this, increase memory usage with not use should not be the case, even though some background process could cause some memory use change, the error in the log it's just an error trying to detect the optimal page chunk size for the system, if it fail will go back to a default value that is good enough most of the times, so nothing to worry on that specific error.

Will keep this open for checking memory usage on idle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants