←back to thread

353 points HunOL | 4 comments | | HN request time: 0s | source
Show context
EionRobb ◴[] No.45784808[source]
One of the biggest contributors I've had in the past for SQLite blocking was disk fragmentation.

We had some old Android tablets using our app 8 hours a day for 3-4 years. They'd complain if locking errors and slowness but every time they'd copy their data to send to us, we couldn't replicate, even on the same hardware. It wasn't until we bought one user a new device and got them to send us the old one that we could check it out. We thought maybe the ssd had worn out over the few years of continual use but installing a dev copy of our app was super fast. In the end what did work was to "defrag" the db file by copying it to a new location, deleting the original, then moving it back to the same name. Boom, no more "unable to open database" errors, no more slow downs.

I tried this on Jellyfin dbs a few months ago after running it for years and then suddenly running into performance issues, it made a big difference there too.

replies(6): >>45784954 #>>45785309 #>>45786705 #>>45787158 #>>45787976 #>>45788856 #
1. didip ◴[] No.45785309[source]
This is fascinating. What would be the solution for this? You can’t ask users to defrag.
replies(1): >>45785462 #
2. DANmode ◴[] No.45785462[source]
Perform the file operation, after zipping the existing db as a backup, and leaving the original where it sits.

Success, performance increase.

Failure, no change.

replies(1): >>45787953 #
3. axitanull ◴[] No.45787953[source]
Forgive my lack of knowledge, but how is simply zipping the original file would "defrag" the file?

Shouldn't the file be moved into different disk fragment first, for that to happen?

replies(1): >>45788902 #
4. DANmode ◴[] No.45788902{3}[source]
That's "the file operation" :]

Again: zip is a backup