starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 23:15:49 +03:00

[GH-ISSUE #556] SQLite vacuum is not called after purging #404

New issue

Closed

opened 2026-02-25 23:42:20 +03:00 by kerem · 5 comments

kerem commented

2026-02-25 23:42:20 +03:00

Owner

Originally created by @OGKevin on GitHub (Aug 26, 2021).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/556

When using SQLite as the database, and you execute one of the purging commands, a lot of records are deleted but the disk usage remains the same.
I've just purged 1GB of data and had to manually execute vacuum to reclaim the disk space.

Is there a possibility to add a check, if DB is SQLlite, to execute vacuum after the purge? Happy to make a PR.

Originally created by @OGKevin on GitHub (Aug 26, 2021). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/556 When using SQLite as the database, and you execute one of the purging commands, a lot of records are deleted but the disk usage remains the same. I've just purged 1GB of data and had to manually execute [vacuum](https://www.sqlite.org/lang_vacuum.html) to reclaim the disk space. Is there a possibility to add a check, if DB is SQLlite, to execute vacuum after the purge? Happy to make a PR.

kerem closed this issue

2026-02-25 23:42:20 +03:00

kerem commented

2026-02-25 23:42:20 +03:00

Author

Owner

@cuu508 commented on GitHub (Aug 27, 2021):

Sounds good, happy to review a PR.

I think vacuuming should be optional, behind a flag:

./manage.py prunepings --vacuum

Why make it optional and opt-in:

Vacuuming can potentially be an expensive operation. In production, it should be done with care. We should follow the principle of least surprise, and not do it by default
Some administrators may specifically want no vacuuming: vacuuming reclaims some disk space in the short term, but under normal usage it will "grow back" (and disk space is cheap)

We will also need to document it in the README.

@cuu508 commented on GitHub (Aug 27, 2021): Sounds good, happy to review a PR. I think vacuuming should be optional, behind a flag: ./manage.py prunepings --vacuum Why make it optional and opt-in: * Vacuuming can potentially be an expensive operation. In production, it should be done with care. We should follow the principle of least surprise, and not do it by default * Some administrators may specifically want *no* vacuuming: vacuuming reclaims some disk space in the short term, but under normal usage it will "grow back" (and disk space is cheap) We will also need to document it in the README.

kerem commented

2026-02-25 23:42:20 +03:00

Author

Owner

@idsvandermolen commented on GitHub (Oct 20, 2021):

I think operational databases in tools like this should not grow endlessly and certainly not as fast as this one with the pings. For now I implemented a work-around by adding these lines the uwsgi.ini file (note we're running this in a container):

hook-asap = exec:./manage.py prunepings && python -c 'import os,sqlite3;con=sqlite3.connect(os.getenv("DB_NAME"));con.execute("VACUUM");con.close()'
attach-daemon = sleep 3600 && echo Terminating healthchecks app && kill 1

The first line cleans up "pings" from the db and reclames disk space with sqlite VACUUM command on uwsgi startup. The second line kills uwsgi after an hour (which is automatically starting again).

@idsvandermolen commented on GitHub (Oct 20, 2021): I think operational databases in tools like this should not grow endlessly and certainly not as fast as this one with the pings. For now I implemented a work-around by adding these lines the `uwsgi.ini` file (note we're running this in a container): ```ini hook-asap = exec:./manage.py prunepings && python -c 'import os,sqlite3;con=sqlite3.connect(os.getenv("DB_NAME"));con.execute("VACUUM");con.close()' attach-daemon = sleep 3600 && echo Terminating healthchecks app && kill 1 ``` The first line cleans up "pings" from the db and reclames disk space with sqlite `VACUUM` command on `uwsgi` startup. The second line kills `uwsgi` after an hour (which is automatically starting again).

kerem commented

2026-02-25 23:42:20 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 21, 2021):

uwsgi has cron-like interface, it lets you run commands on a regular interval.

Try something like this in uwsgi.ini:

cron =  5 -1 -1 -1 -1  python manage.py prunepings

@cuu508 commented on GitHub (Oct 21, 2021): uwsgi has [cron-like interface](https://uwsgi-docs.readthedocs.io/en/latest/Cron.html), it lets you run commands on a regular interval. Try something like this in `uwsgi.ini`: ``` cron = 5 -1 -1 -1 -1 python manage.py prunepings ```

kerem commented

2026-02-25 23:42:20 +03:00

Author

Owner

@cuu508 commented on GitHub (Oct 21, 2021):

I just pushed a commit which adds automatic api_ping and api_notification cleanup. And it removes the prunepings, prunepingsslow and prunenotifications management commands.

The automatic cleanup happens when processing a received ping: after saving a ping to the database, Healthchecks now also removes old pings and notifications. But, to reduce overhead, it only does this every 100 received pings.

@cuu508 commented on GitHub (Oct 21, 2021): I just pushed a commit which adds automatic `api_ping` and `api_notification` cleanup. And it removes the `prunepings`, `prunepingsslow` and `prunenotifications` management commands. The automatic cleanup happens when processing a received ping: after saving a ping to the database, Healthchecks now also removes old pings and notifications. But, to reduce overhead, it only does this every 100 received pings.

kerem commented

2026-02-25 23:42:21 +03:00

Author

Owner

@idsvandermolen commented on GitHub (Oct 21, 2021):

@cuu508 Excellent! For reference, here's the commit github.com/healthchecks/healthchecks@e1f51093f1

@idsvandermolen commented on GitHub (Oct 21, 2021): @cuu508 Excellent! For reference, here's the commit https://github.com/healthchecks/healthchecks/commit/e1f51093f1cc913fc71d5507038de7787dafafae