!QtykxKocfZaZOUrTwp:matrix.org

Matrix HQ

1109 Members
The Official Matrix HQ - please come chat here! | Room reborn 2018-06-11 to flush ancient state | To support Matrix.org development: https://patreon.com/matrixdotorg | Looking for hosting? Check out https://upcloud.com/matrix!181 Servers

Load older messages


Timestamp Message
15 Jul 2018
18:44:43@/dev/ponies:ponies.im/dev/poniesthough they need some serious optimisation on the scrollback and fill apis
18:44:54@jaywink:feneas.orgJason RobinsonGood to know 👍
18:45:04@/dev/ponies:ponies.im/dev/poniesit should take no more than 5 seconds to fetch scrollback even if it has to call another homeserver
18:45:12@/dev/ponies:ponies.im/dev/ponies

eeeeeta: yeah i meant vacuum full

18:45:17@/dev/ponies:ponies.im/dev/poniesautovacuum does basically nothing
18:45:33@/dev/ponies:ponies.im/dev/poniesif a vacuum full can shrink your db by 6-12% than autovacuum is worthless lol
18:45:41@freenode_eeeeeta:matrix.orgeeeeeta (IRC)devponies[m]: AFAIK it frees up space for postgres itself though
18:45:52@flux:matrix.orgfluxvacuum full actually returns the space to the file system, but if your intention is to fill it again with the same db, then isn't autovacuum ok?
18:46:16@freenode_eeeeeta:matrix.orgeeeeeta (IRC)AFAIK vacuum (normal) = figure out which rows are stale, vacuum full = actually rewrite the whole DB in order to hand free space to the OS
18:46:28@freenode_eeeeeta:matrix.orgeeeeeta (IRC) flux[m]: yeah, that's what I reckon
18:46:33@jaywink:feneas.orgJason Robinson Yeah the point isn't to shrink, it's to limit growth
18:47:09@/dev/ponies:ponies.im/dev/ponies

flux: possibly, but it didn't seem to be doing that considering our db kept growing regardless

18:47:21@/dev/ponies:ponies.im/dev/poniesif 6-12% was empty than it shouldn't have kept growing on the disk
18:48:27@flux:matrix.orgfluxI suppose the normal autovacuum isn't quite as aggressive as vacuum full is, though
18:50:26@/dev/ponies:ponies.im/dev/poniesi think the conclusion is that postgresql does a terrible job of freeing up space for re-use
18:48:53@flux:matrix.orgfluxand might be hindered if there's something using certain tables during the operation contantly?
18:49:14@freenode_eeeeeta:matrix.orgeeeeeta (IRC)devponies[m]: also might be due to index bloat, etc
18:49:52@flux:matrix.orgfluxchecking database object sizes before and after vacuum might provide some insight
18:51:40@flux:matrix.orgfluxjust buy more ssd ;)
18:51:41@willem:canarymod.netWillemVacuum full implies you need at least the biggest table worth of free space on disk, unfortunately
18:51:42@freenode_eeeeeta:matrix.orgeeeeeta (IRC)take a look at https://www.postgresql.org/docs/9.1/static/routine-vacuuming.html
18:52:11@/dev/ponies:ponies.im/dev/ponies

eeeeeta: reindexing takes like 5 hours lol

18:52:14@q6wgrkd8tr9o49j8:disroot.orgLrrrdoes any do it better thant postgres?
18:52:29@flux:matrix.orgflux if your environment is such that you are able to run vacuum full without causing expensive downtime, then I think it might not be the worst idea to just do it :), at least you have a good idea how much the database 'actually' takes.
18:52:44@/dev/ponies:ponies.im/dev/poniesprobably not
18:53:45@freenode_eeeeeta:matrix.orgeeeeeta (IRC) flux[m]: nah, constant VACUUM FULLs aren't great
18:53:50@freenode_eeeeeta:matrix.orgeeeeeta (IRC) they're a bit wasteful
18:54:28@flux:matrix.orgfluxwell it's like the question if you should do incremental backups or just full backups
18:55:03@flux:matrix.orgfluxrealistically one must do incrementals because there's almost always that much data that doing it otherwise would be impractical. but if you can do fulls, then be my guest, at least you know you have everything :-).
19:03:16@q6wgrkd8tr9o49j8:disroot.orgLrrrnuke it from orbit /s

There are no newer messages yet.


Back to Room List