timescaledb-tune uses the wrong values when executed in a resource-constrained container

[maltalex]

Hi Guys

The title is self-explanatory, but here's a reproduction anyway:

1. Run timescale container with limited cpu and memory:

docker run --rm -d --name temp --cpus 1 --memory 1g timescale/timescaledb:1.5.1-pg11

2. Run timescale-tune. Note the number of detected CPUs and memory:

$ docker exec temp timescaledb-tune -dry-run -yes
Using postgresql.conf at this path:
/var/lib/postgresql/data/postgresql.conf

success: shared_preload_libraries is set correctly

Recommendations based on 125.85 GB of available memory and 32 CPUs for PostgreSQL 11
Memory settings recommendations
Current:
Recommended:
success: memory settings will be updated
Parallelism settings recommendations

shared_buffers = 256MB
effective_cache_size = 768MB
maintenance_work_mem = 128MB
work_mem = 82kB
shared_buffers = 32218MB
effective_cache_size = 96654MB
maintenance_work_mem = 2047MB
work_mem = 10309kB


wal_buffers = 7864kB
wal_buffers = 16MB

max_locks_per_transaction = 64
max_locks_per_transaction = 512
success: parallelism settings are already tuned
WAL settings recommendations
Current:
Recommended:
success: WAL settings will be updated
Miscellaneous settings recommendations
Current:
Recommended:
success: miscellaneous settings will be updated
Success, but not writing due to --dry-run flag

[RobAtticus]

So by default our Docker image already runs timescaledb-tune so you wouldn't need to run it again in the Docker container.

That being said, there's a couple of things going on here, and I'm not sure exactly what the right solution should be.

First, when we run timescaledb-tune within Docker, we do some extra work to make sure we are getting the right container memory and CPU settings. The file that does that is here:
https://github.com/timescale/timescaledb-docker/blob/master/docker-entrypoint-initdb.d/002_timescaledb_tune.sh

Using the same setup you gave, and adding --dry-run to the ending command I see this:

Using postgresql.conf at this path:
/var/lib/postgresql/data/postgresql.conf

Recommendations based on 1.00 GB of available memory and 2 CPUs for PostgreSQL 11
success: all settings tuned, no changes needed
Success, but not writing due to --dry-run flag

So when its run inside the container, it is coming up with the correct amount of memory (1GB), so any of those settings should be correct.

Now, the CPU number is seemingly incorrect, but really I think its just a quirk of how Docker works here. While we are specifying CPU of 1, that doesn't mean it gets exactly 1 CPU to use, but rather it gets the equivalent of 1 CPU potentially split across all CPUs. I don't think we have any good way to detect what are CPU equivalent of is here, or even if we want to. The number of CPUs mostly determine the parallelization that is available, and we do have 2 CPUs to use, they will just run at about half speed. You could actually use the --cpuset-cpus to pin Docker to one specific CPU but that might not be ideal. However, then timescaledb-tune will detect only 1 CPU.

---

The one thing we might consider doing in our Docker images is aliasing timescaledb-tune to use the entrypoint script above so that it always makes sure to do the memory / CPU calculations correctly in case you do decide to re-run it.

Hope this helps!

[maltalex]

The one thing we might consider doing in our Docker images is aliasing timescaledb-tune to use the entrypoint script above so that it always makes sure to do the memory / CPU calculations correctly in case you do decide to re-run it.

That would work, but perhaps a cleaner solution would be to incorporate the docker-related hacks into the timescaledb-tune utility itself instead of relying on the entrypoint script to provide the correct values.

That way, the right values will be used regardless of how the utility is executed.