ConceptsResource limits
Upgrade from a Ferry with no limits
After the upgrade, a container gets its limits when a deploy or a restart replaces it.
You upgrade Ferry. The containers that run continue with no limit.
1 / 3
An older Ferry started each container with no resource limit. The upgrade does not change a container that runs.
Set the limits of a large app first
The kernel stops an app or a database that needs more than 512 MiB when it gets the default limit. Give it sufficient memory immediately after the upgrade.
Give more memory
ferry update NAME --memory 2G # a service
ferry restart NAME
ferry db update NAME --memory 2G # a datastore: applies immediatelyYou can also start ferryd with a higher --default-memory-limit.
What changes, and when
| Thing | After the upgrade |
|---|---|
| Containers of a service | No limit until a deploy or a restart replaces them. Then they get the limits of the service, or the server defaults (512 MiB, 1 CPU). |
| A scale or a crash, before that deploy | The new container starts from the old deploy, with the server defaults. |
| Datastores | No limit until you change their limits, or until Ferry creates their container again. Ferry applies nothing when ferryd starts. |
| Blueprints | Before, Ferry ignored plan. The first apply restarts each live service with a plan, and changes the limits of each datastore with a plan. |
A datastore also gets limits when Ferry provisions it again, for example a retry after a failure.
ferry db update puts the limit on the container that runs.