mirrors/gotosocial
1
0
Fork 1
mirror of https://github.com/superseriousbusiness/gotosocial.git synced 2024-06-12 18:29:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

update docs, analyze

Browse source
This commit is contained in:
tobi 2024-03-14 17:44:04 +01:00
parent b6c00dde2c
commit 266db7b05c
2 changed files with 28 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
docs/admin/database_maintenance.md
View file

@ -2,32 +2,48 @@
Regardless of whether you choose to run GoToSocial with SQLite or Postgres, you may need to occasionally take maintenance steps to keep your database running well.
!!! tip
Though the maintenance tips provided here are intended by non-destructive, you should still consider backing up your database before manually intervening to do maintenance. That way if you mistype something or accidentally run a bad command, you can simply restore your backup and try again.
!!! danger
Manually creating, deleting, or updating entries in your GoToSocial database is **heavily discouraged**, and such commands are not provided here. Even if you think you know what you are doing, running `DELETE` statements etc. may introduce issues that are very difficult to debug. The maintenance tips below are designed to help with the smooth running of your instance; they will not save your ass if you have manually gone into your database and hacked at entries, tables, and indexes.
## SQLite
To do manual SQLite maintenance, you should first install the SQLite command line tool `sqlite3` on the same machine that your GoToSocial sqlite.db file is stored on. See [here](https://sqlite.org/cli.html) for details about `sqlite3`.
### Analyze / Optimize
Following [SQLite best practice](https://sqlite.org/lang_analyze.html#recommended_usage_pattern), GoToSocial runs the `optimize` SQLite pragma with `analysis_limit=1000` on closing database connections to keep index information up to date.
After each database migration, GoToSocial will also run `ANALYZE` with `analysis_limit=10000` to ensure that any indexes added or removed by migrations are taken into account.
After each set of database migrations (eg., when starting a newer version of GoToSocial), GoToSocial will run `ANALYZE` to ensure that any indexes added or removed by migrations are taken into account correctly by the query planner.
As such, in normal circumstances, you should not need to run manual `ANALYZE` commands against your SQLite database file.
The `ANALYZE` command may take ~10 minutes depending on your hardware and the size of your database file.
However, if you interrupted a previous `ANALYZE` command, it could be the case that query optimizer data stored in SQLite's internal tables has been removed, and you notice that queries are running remarkably slowly.
Because of the above automated steps, in normal circumstances you should not need to run manual `ANALYZE` commands against your SQLite database file.
If this is the case, you can try manually running an `ANALYZE` command in the SQLite CLI tool, by entering: `PRAGMA analysis_limit=10000; ANALYZE;`.
However, if you interrupted a previous `ANALYZE` command, and you notice that queries are running remarkably slowly, it could be the case that the index metadata stored in SQLite's internal tables has been removed or undesirably altered.
It is not necessary to run a full analyze, an approximate analyze will do. [See here](https://sqlite.org/lang_analyze.html#approximate_analyze_for_large_databases) for more info.
If this is the case, you can try manually running a full `ANALYZE` command, by doing the following:
1. Stop GoToSocial.
2. While connected to your GoToSocial database file in the `sqlite3` shell, run `PRAGMA analysis_limit=0; ANALYZE;` (this may take quite a few minutes).
3. Start GoToSocial.
[See here](https://sqlite.org/lang_analyze.html#approximate_analyze_for_large_databases) for more info.
### Vacuum
GoToSocial does not currently enable auto-vacuum for SQLite. As such, you may want to periodically (eg., every few months) run a `VACUUM` command on your SQLite database, to repack the database file to an optimal size.
GoToSocial does not currently enable auto-vacuum for SQLite. To repack the database file to an optimal size you may want to run a `VACUUM` command on your SQLite database periodically (eg., every few months).
You can see lots of information about the `VACUUM` command [here](https://sqlite.org/lang_vacuum.html).
The basic steps are:
1. Stop GoToSocial.
2. Run `VACUUM` using the SQLite CLI tool (this may take quite a few minutes depending on the size of your database file).
2. While connected to your GoToSocial database file in the `sqlite3` shell, run `VACUUM;` (this may take quite a few minutes).
3. Start GoToSocial.
## Postgres

7
internal/db/bundb/bundb.go
View file

@ -112,8 +112,11 @@ func doMigration(ctx context.Context, db *bun.DB) error {
log.Infof(ctx, "MIGRATED DATABASE TO %s", group)
if db.Dialect().Name() == dialect.SQLite {
log.Info(ctx, "running ANALYZE to update table and index statistics")
_, err := db.ExecContext(ctx, "PRAGMA analysis_limit=10000; ANALYZE")
log.Info(ctx,
"running ANALYZE to update table and index statistics; this may take 10 minutes or "+
"longer depending on your hardware and database size, please be patient",
)
_, err := db.ExecContext(ctx, "ANALYZE")
if err != nil {
log.Warnf(ctx, "ANALYZE failed, query planner may make poor life choices: %s", err)
}