- Aptible CLI
- aptible apps
- aptible apps:create
- aptible apps:deprovision
- aptible apps:rename
- aptible apps:scale
- aptible backup:list
- aptible backup:orphaned
- aptible backup:purge
- aptible backup:restore
- aptible config
- aptible config:add
- aptible config:rm
- aptible config:set
- aptible config:unset
- aptible db:backup
- aptible db:clone
- aptible db:create
- aptible db:deprovision
- aptible db:dump
- aptible db:execute
- aptible db:list
- aptible db:modify
- aptible db:reload
- aptible db:rename
- aptible db:replicate
- aptible db:restart
- aptible db:tunnel
- aptible db:url
- aptible db:versions
- aptible deploy
- aptible domains
- aptible endpoints:database:create
- aptible endpoints:database:modify
- aptible endpoints:deprovision
- aptible endpoints:https:create
- aptible endpoints:https:modify
- aptible endpoints:list
- aptible endpoints:renew
- aptible endpoints:tcp:create
- aptible endpoints:tcp:modify
- aptible endpoints:tls:create
- aptible endpoints:tls:modify
- aptible environment:ca_cert
- aptible environment:list
- aptible environment:rename
- aptible help
- aptible log_drain:create:datadog
- aptible log_drain:create:elasticsearch
- aptible log_drain:create:https
- aptible log_drain:create:logdna
- aptible log_drain:create:papertrail
- aptible log_drain:create:sumologic
- aptible log_drain:create:syslog
- aptible log_drain:deprovision
- aptible log_drain:list
- aptible login
- aptible logs
- aptible logs_from_archive
- aptible metric_drain:create:datadog
- aptible metric_drain:create:influxdb
- aptible metric_drain:create:influxdb:custom
- aptible metric_drain:deprovision
- aptible metric_drain:list
- aptible operation:cancel
- aptible operation:follow
- aptible operation:logs
- aptible rebuild
- aptible restart
- aptible services
- aptible ssh
- aptible version
- Application Performance Monitoring
- CI Integration
- Aptible Demo App
- Deploying Grafana
- Direct Docker Image Deploy Example
- Dockerfile Deploy Example
- Exposing a Web App to the Internet
- Using Nginx with Aptible Endpoints
- Quickstart Guides
- Setting up Logging
- Automating Database Migrations
- Dockerfile Caching
- Using Domain Apex with Endpoints
- Accepting File Uploads
- Scheduling Tasks
- Serving Static Assets
- How to test a PostgreSQL Database's schema on a new version
- How to dump and restore PostgreSQL
- How to upgrade PostgreSQL with logical replication
- How to upgrade Redis
- How to upgrade MongoDB
- How to use mysqldump to Test for Upgrade Incompatabilities
- How to dump and restore MySQL
- Aptible Support
- App Processing Requests Slowly
- This Application Crashed
- before_release Commands Failed
- Build Failed
- Container Failed to Start
- Certificate Signing Requests
- Deploys Take Too long
- git Reference Error
- git Push "Everything up-to-date."
- HTTP Health Checks Failed
- App Logs Not Being Received
- PostgreSQL Replica max_connections
- Connecting to MongoDB fails
- MySQL Access Denied
- No CMD or Procfile in Image
- git Push Permission Denied
- aptible ssh Permission Denied
- PostgreSQL Incomplete Startup Packet
- PostgreSQL SSL Off
- Private Key Must Match Certificate
- aptible ssh Operation Timed Out
- SSL error ERR_CERT_AUTHORITY_INVALID
- SSL error ERR_CERT_COMMON_NAME_INVALID
- Unexpected Requests in App Logs
Container size is set by the Memory and CPU is determined by the ratio of Memory to CPU that is unique to each Container Profile. Aptible deploys containers for all resources within a Stack across multiple host machines, each with a fixed size. For example, a host for Apps with 8GB of RAM might be running one 4GB container and two 1GB containers (all with the General Purpose profile), leaving the host with 2GB of unallocated resources. Aptible only guarantees that a container will be placed on a host machine which has at least enough CPU and memory to fit the container's CPU and memory limits. It is possible, but not always true, that the host machine might have more than the Container needs but it is always true that it has at least the exact amount of needed resources.
Memory Limits are always enabled which means that in the case that a container exceeds its memory allocation, it is restarted to ensure the host machine and other containers stay healthy. Likewise, CPU Limits are always enabled on Shared Stacks, where containers are throttled if they exceed their CPU Limit, which is determined by the container's size. This ensures that malfunctioning or undersized containers do not affect other users' containers located on the same host machine. In contrast, CPU Limits have not always been enabled on Dedicated Stacks. Without CPU Limits enabled, containers can use any available processing resources on the underlying host machine without being throttled but could potentially jeopardize other containers on the same host.
Why should CPU Limits be enabled on Dedicated Stacks?
Without CPU limits, there are a few important implications for Containers deployed on Dedicated Stacks:
- Containers will be allowed to use more CPU than their share.
- Containers may negatively impact other Containers on the Dedicated Stack if they use too much CPU.
In the absence of CPU Limits, Containers are granted extra CPU that was not allocated to them, but their CPU share is not guaranteed. Conversely, if CPU Limits are enabled, Containers are limited to their resource allocation, but that allocation is guaranteed.
✅ Enable CPU Limits!
Aptible strongly recommends enabling CPU Limits on existing Dedicated Stacks which do not currently have CPU Limits enabled.
Without CPU Limits, a container can be starved of CPU by other containers allocated in the same host machine. If another container on the same host exceeds its limit and consumes all available CPU on the host machine, an App can time out, throw errors, and trigger alerting. When an alert is triggered by a sudden increase in load on another Service, a CPU-intensive cron job, or a bad release of another App on the Dedicated Stack, it can be difficult to narrow down the true cause of the problem.
Moreover, the underlying events that trigger these types of errors might not be visible at all:
- The Aptible platform may restart containers on different hosts at any time, in response to a host machine failure or scheduled maintenance.
- Ephemeral SSH Sessions without CPU Limits enabled may cause CPU starvation of Stack resources which are colocated with the bastion host instance—including the NAT Gateway, which will affect all outbound traffic.
- App host machines may be replaced with larger or smaller machines (typically, a seamless transition), and if the excess CPU capacity an undersized Container was relying on suddenly disappears, it may induce a sudden, inexplicable drop in App performance!
CPU Limits prevent these failure modes entirely.
What is the process to enable CPU Limits?
Please contact Aptible Support to enable CPU Limits. Since there is a risk that Apps without enforced CPU Limits are relying on resources beyond their nominal allocation, enabling CPU Limits on Dedicated Stacks is not trivial. Aptible Support will generate a report outlining which, if any, services need to be scaled up before CPU Limits are enabled. Once users confirm that services which need additional resources have been adequately scaled up, the Support team will enable CPU Limits on the Dedicated Stack.
How long does it take to enable CPU Limits?
Aptible Support can generate the report to identify if any services need to be scaled up within 24 hours. Once services are adequately scaled up and confirmation is sent to Aptible Support, CPU Limits can be enabled within 24 hours. There is no downtime involved in this process.
Can CPU Limits be enabled on Shared Stacks?
CPU Limits and Memory Limits are enforced on Shared Stacks by default. It is not possible to disable these limits on a Shared Stack.
Can CPU Limits be disabled on Dedicated Stacks?
No, it is not possible to disable CPU Limits after they are enabled. CPU Limits are enabled by default on all new Stacks as of 2021.
Why were CPU Limits disabled in the past?
CPU Limits were disabled in the past to provide surge capacity for individual services within a Dedicated Stack. Disabled CPU Limit limits meant that excess CPU capacity on the host machine will not go unused if a container is taxed beyond its allocation. This allowed Containers which required increased resources for a short period to have access to as much processing power as was available on the host machine.