High disk write activity (database.db) after 2.7.0 update

[kuema]

What happened?

Hi,

I have z2m setup as a Docker container.
After updating to 2.7.0, I noticed an increase in disk writes. From some Megabytes a day to several Gigabytes.

It seems with 2.7 the database.db gets written at least every second. Previous versions updated this file only a few times a day.
My database.db is around 140kb. So, depending on its size, it amounts up to several GB a day, which can lead to significant wear when running on SD cards.

I rolled back to 2.6.3, and the write load is back to nearly zero.

Could this be related to the new activity features for the UI?

What did you expect to happen?

Low disk write activity in the range of several MB per day, as with previous version.

How to reproduce it (minimal and precise)

Update to 2.7.0 and monitor disk activity via Docker stats (e.g. Portainer) or iotop.

Zigbee2MQTT version

2.7.0

Adapter firmware version

20240710

Adapter

CC2652P stick

Setup

Docker container on x86_64 Linux

Linux zeus 6.1.0-40-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.153-1 (2025-09-20) x86_64 GNU/Linux

Device database.db entry

No response

Debug log

No response

Notes

No response

[jonathanathe]

I’m not sure if that’s the problem, but it’s true that after updating to version 2.7.0-1 it stopped working and there was no way to fix it. I had to roll back to the previous version.

[kuema]

What has stopped working?

Just to be clear, I had no issues after updating to 2.7.0 in terms of functionality or features. Everything was working properly.

However, I noticed the significant increase in disk write activity related to database.db, which this issue is about.

[snok3r-krk]

I have the same issue. Functionally, everything works in 2.7.0, but writes have increased by approximately 200MB per hour. After reverting back to 2.6.3, writes returned to the expected amount.

I am using HAOS with z2m addon.

[jonathanathe]

¿Qué ha dejado de funcionar?

Para que quede claro, no tuve problemas después de actualizar a 2.7.0 en términos de funcionalidad o características. Todo estaba funcionando correctamente.

Sin embargo, noté el aumento significativo en la actividad de escritura en disco relacionada con database.db, de lo que trata este número.

In my case, just like in @snok3r-krk comment, I’m using HAOS with the Z2M addon. After the update, it seems to start up and runs for a bit, but it’s extremely slow, then crashes and restarts again. As I mentioned before, rolling back to the previous version makes it work perfectly and run fast.

[sevrob]

I see the same, a big growth in BLOCK I/O. Not on SDcard so not a big deal for me, but unneccessary.

[kuema]

I see the same, a big growth in BLOCK I/O. Not on SDcard so not a big deal for me, but unneccessary.

I'm glad I'm not the only one seeing this! 🤓
My system runs on an NVME SSD, but those writes are unneccessary and could pose serious problems for users running on SD cards (RPi...).

In my case, just like in @snok3r-krk comment, I’m using HAOS with the Z2M addon. After the update, it seems to start up and runs for a bit, but it’s extremely slow, then crashes and restarts again. As I mentioned before, rolling back to the previous version makes it work perfectly and run fast.

I don't think that this is related, unless your storage is really slow, e.g. running everything from SD card.
It shouldn't have any noticeable impact on performance. But then, the whole system would be impacted anyway.

In essence, something has been changed in the write/update frequency of the database.db file.
But I'm not familiar with the code base to track it down any further than I already have.

[Nerivec]

@Koenkk I guess the only change that could possibly do this is https://github.com/Koenkk/zigbee-herdsman/blob/446015948bb84d71f1f02cd980836a45f24bff07/src/controller/model/endpoint.ts#L308
It previously did not save there. I suppose if some devices are reporting very frequently, this could amount to a noticeable change.
I see two options:

• remove it, but risk outdated data if Z2M ever crashes (will matter for proper sync with reporting & upcoming scenes refactor)
• debounce it, so it triggers only once every X seconds.

@kuema are you able to locate that line in your installation, and just remove it, to confirm it is indeed the cause? (would be in node_modules/.pnpm/zigbee-herdsman@7.0.2/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js around line 200)

[MartB]

I have a tuya device that updates every second which I can't fix, so yeah if that also causes writes to that file that wouldn't be ideal

[kuema]

Yes, I have a bunch of devices and frequent incoming messages.

However database.db only got updated once every hour or so since I've reverted back to 2.6.3 this morning.
Is there a fixed interval for the db update < 2.7 regardless of changes?
If so, the risk of outdated data would have been there the whole time prior to that change.

But I think even reducing it to once every X seconds could still be too much, I'd go in the range of minutes, or maybe make this timer configurable.

Tomorrow, I will update to 2.7.0 again and remove/comment the line you suggested and report back to you.

[Nerivec]

A fix was pushed in dev branch, if you can confirm it reduces the I/O back to a "normal" state. Koenkk/zigbee-herdsman#1576
Should be available in 20min or so.

[kuema]

Thanks for the quick fix! I just tested the latest-dev Container image.

Running about 90min and got about 3.3MB of disk writes, that's magnitudes lower compared with before. 👍
I think that's acceptable, even for setups on SD cards.

Any chance this flush interval can make it into the settings, so everyone can tailor it to their usage scenario?
z2m is running rock-solid in my setup, no crashes ever. 👍 So once per hour was perfectly fine for me.

(I restarted once to check if the db gets saved on a graceful shutdown.)