[solved] MapDB growing indefinitely

Add-ons Persistence Services
, ,
1

Hi,
my mapdb is growing indefinitely filling my disk completely after some time.

I’ve searched the community for a relating issue, but nothing covered my issue or I didn’t recognize it.

My persistence rules are default and set in the UI

*, restoreOnStartup,everyChange.

Is there anything I’m missing or a way to frequently shrink the database?

Thanks a lot

2

This is very unexpected. Mapdb only keeps one entry for every item, and replaces it when the item gets updated. I can’t see how it can grow indefinitely. It should stop growing once all items have been changed at least once.

What system are you running on? Could there be an SD card corruption in play?

How many items do you have? Do you frequently create items with new names? Old items may keep hanging around in there.

You can always stop OH, delete the database and start again. The only inconvenience will be item states will not be restored at the start, but only on the first update. Mapdb will grow the, until all items have been persisted (and a bit more, as the previous state will also be persisted on the next change), but that should be it.

3

My system is a Proxmox LXC container and in my system are currently 805 items. It’s a very stable system where very little items are created. I actually can’t remember when i did it the last time.

The system base is Debian.

Previously my system was dockerized and I noticed the same behavior, but not to such an extent. Caches were already cleared and mapdb deleted, but it happens again.

To give you a figure. When I restored my system from a backup and deleted mapdb on last Thursday. It grew like this

Time MapDB size remark
16.4. at 20:33 0
17.4. at 0:17 75 MiB (~4 hours later)
18.4. at 0:17 850 MiB
19.4. at 0:17 1.66 GiB

This is insane. Any idea how i can track the cause?

4

Yes strange.
My set up is years old and I have 450 items.

ll /var/lib/openhab/persistence/mapdb
Permissions Size User    Date Modified    Name
drwxr-xr-x     - openhab 2025-10-02 09:53 backup/
.rwxr-xr-x    32 openhab 2026-04-14 17:43 Readme.txt*
.rw-r--r--   33k openhab 2026-04-19 15:34 storage.mapdb
.rw-r--r--  185M openhab 2026-04-19 15:34 storage.mapdb.p
.rw-r--r--    16 openhab 2026-04-19 15:34 storage.mapdb.t

My mapdb config:

configurations:
  - items:
      - "*"
    strategies:
      - everyChange
      - restoreOnStartup
    filters: []
aliases: {}
cronStrategies: []
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

I did all my config via the UI.

5

Same here

configurations:
  - items:
      - "*"
    strategies:
      - restoreOnStartup
      - everyChange
    filters: []
aliases: {}
cronStrategies: []
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

but using much more space

 ls -alh /var/lib/openhab/persistence/mapdb/
total 1.8G
drwxr-xr-x 2 openhab openhab 4.0K Mar 26 11:46 .
drwxr-xr-x 5 openhab openhab 4.0K Mar 26 11:46 ..
-rwxr-xr-x 1 openhab openhab   32 Feb 22 22:31 Readme.txt
-rw-r--r-- 1 openhab openhab  33K Jan 26 02:01 storage.mapdb
-rw-r--r-- 1 openhab openhab 2.0M Jan 26 02:01 storage.mapdb.p
-rw-r--r-- 1 openhab openhab 2.0G Apr 19 10:04 storage.mapdb.t

It’s interesting that your storage.mapdb.p file is much larger than mine. And vice versa my storage.mapdb.t file is huge compared to yours. May be this is a route worth looking at.

Anyone an idea how to troubleshoot this issue?

6

Solved the problem now with the help of AI

The root cause as explained by the AI

  • Transaction Log Bloat: The .t file is a “Write Ahead Log” (transaction log). MapDB appends every single change to this file first. In a healthy state, these changes are merged into the main .p file and the .t file is cleared.
  • High-Frequency Items: If you have “noisy” items (e.g., power meters, signal strength sensors, or rapidly updating temperature probes), they generate thousands of writes. MapDB 1.0 (used in openHAB) often struggles to clear the log as fast as it grows when the volume is this high.
  • The “Commit” Failure: Once the .t file reaches a certain size (often 2GB or 4GB depending on the JVM/system), the internal memory-mapping can fail or become extremely slow, preventing the “commit” process from ever successfully shrinking the file.

My Solution

Get rid of the “*” for items and create a group for hosting the persisted items that make sense to be restored on startup. As I have about 800 Items with lots of them being statuse

  • Listed all Items in the console with openhab:items list and asked the AI which Items are good candidates for a restore group
  • Checked the resulting candidates and had the AI create a script to add these items to my restore group

This way I reduced the number of items to be restored to around 30.

Now my mapdb directory looks like this

root@center-openhab:~# ls -alh /var/lib/openhab/persistence/mapdb/
total 64K
drwxr-xr-x 2 openhab openhab 4.0K Apr 22 20:43 .
drwxr-xr-x 5 openhab openhab 4.0K Mar 26 11:46 ..
-rwxr-xr-x 1 openhab openhab   32 Feb 22 22:31 Readme.txt
-rw-r--r-- 1 openhab openhab  33K Apr 22 22:20 storage.mapdb
-rw-r--r-- 1 openhab openhab  12K Apr 22 22:20 storage.mapdb.p
-rw-r--r-- 1 openhab openhab   16 Apr 22 22:20 storage.mapdb.t

Issue solved

May be this helps anyone with the same issue

7

@dolittle Can you mark your last post as the solution, so other people can easily find it? Thank you for your effort.