Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 installre-uses a compose file it finds on disk, so an install that follows adelete --keep-configkeeps the old one, limits included.