Skip to content

feat(installer): set container resource limits on a new TestGen install - #97

Open
aarthy-dk wants to merge 1 commit into
mainfrom
feat/default-container-resource-limits
Open

aarthy-dk wants to merge 1 commit into
mainfrom
feat/default-container-resource-limits

Conversation

@aarthy-dk

Copy link
Copy Markdown
Contributor

Both services ran with no ceiling at all. That reads as generous and is the opposite: with no limit there is nothing for the container to hit, so the host runs out of memory instead and the kernel picks a victim by size -- which can be the database, or anything else sharing the machine. With a limit, a run that exhausts memory is confined to the container it started in and the rest keeps serving.

Sized for the 4 CPU / 16 GB virtual machine the enterprise install guide asks for, matching the example compose files that ship with TestGen. They are ceilings rather than reservations, so the two overlap deliberately and a smaller evaluation machine simply never reaches them.

New installs only. The upgrade path patches an existing compose file key by key and is deliberately left alone: imposing a ceiling on a running install could start killing work that fits the machine it was sized for, and that decision belongs to whoever sized it. A test pins that, so a later backfill has to be deliberate.

Note this is new installs by compose file, not by command -- tg install re-uses a compose file it finds on disk, so an install that follows a delete --keep-config keeps the old one, limits included.

Both services ran with no ceiling at all. That reads as generous and is the
opposite: with no limit there is nothing for the container to hit, so the host
runs out of memory instead and the kernel picks a victim by size -- which can be
the database, or anything else sharing the machine. With a limit, a run that
exhausts memory is confined to the container it started in and the rest keeps
serving.

Sized for the 4 CPU / 16 GB virtual machine the enterprise install guide asks
for, matching the example compose files that ship with TestGen. They are
ceilings rather than reservations, so the two overlap deliberately and a smaller
evaluation machine simply never reaches them.

New installs only. The upgrade path patches an existing compose file key by key
and is deliberately left alone: imposing a ceiling on a running install could
start killing work that fits the machine it was sized for, and that decision
belongs to whoever sized it. A test pins that, so a later backfill has to be
deliberate.

Note this is new installs by compose file, not by command -- `tg install`
re-uses a compose file it finds on disk, so an install that follows a
`delete --keep-config` keeps the old one, limits included.
@aarthy-dk
aarthy-dk requested a review from rboni-dk September 15, 2026 23:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant