We have recently reduced the volume size of our Postgres app. The volume size was 10 GB and used space was 750 MB. After the volume is reduced to 2 GB, the used space became 280 MB.
Two questions:
used space shrinked when the volume size shrinked?Hi… It’s commonplace for reports of used space to include the operating system’s own bookkeeping datastructures and reservations, which tend to scale with the volume’s total capacity. Consequently, it’s not alarming to see a decrease in this situation…
Moreover, different sources will report different values (and we forum readers don’t know which one you were consulting in this particular case!), even on the exact same disk.
For example, I just created a new PG Flex database with a 10GB volume. The Grafana dashboard says 481MiB used, whereas df and du claim only 47MB (i.e., roughly a tenth). This is really only down to differences in what is and is not included in the tally.
In terms of knowing how much leeway you have for additional stuff, I would trust…
$ fly ssh console -C 'df -h /data' -a db-app-name
Filesystem Size Used Avail Use% Mounted on
/dev/vdc 9.9G 47M 9.4G 1% /data
The 9.4G (Avail) is really what you want, in my opinion.
If OS’s own bookkeeping datastructures increase with the volume size, does it speed up the database queries? In our case, we have reduced the volume size, thus the used space has also shrinked. Does it mean we will experience degraded database performance?
No, not from the OS’s datastructures.
You could keep an eye on Avail, making sure that it stays reasonable when a lot of transactions are in progress, etc., if you have an intuition that things might be a little worse now.
(See also the recent thread about CPU throttling and its discussion about the current inconsistency of CPU performance on the Fly.io platform.)
Postgres responsiveness can get pretty complicated, overall, but usually the filesystem metadata is not the prime suspect…
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.