-
Notifications
You must be signed in to change notification settings - Fork 9
dynos
A dyno, the basic unit of composition on Heroku, is a lightweight container running a single user-specified command. You can think of it as a virtualized unix container---it can run any command that makes sense given the default environment in that container (what we supply in the Cedar stack), and in your slug (which will be based on your code and language run times).
The commands run within dynos include web processes, worker processes (such as timed jobs and queuing systems), and any process types declared in the app’s Procfile. One-off admin processes are also run within dynos.
-
Elasticity & scale: The number of dynos allocated for your app can be increased or decreased at any time. Read more about scaling your dynos.
-
Intelligent routing: The routing mesh tracks the location of all dynos running web processes (web dynos) and routes HTTP traffic to them accordingly.
-
Process management: Resident processes are monitored for responsiveness. Dynos with misbehaving processes are taken down and new dynos are launched in their place.
-
Distribution and redundancy: Dynos are distributed across an elastic execution environment known as the dyno manifold. An app configured with two web dynos hosts two web processes, as you'd expect, but each process is running in a separate physical location. If underlying infrastructure fails your site stays up - even with only two dynos.
-
Isolation: Every dyno is completely isolated in its own subvirtualized container with many benefits for security, resource guarantees, and overall robustness.
Each dyno is allocated 512MB of memory to operate within. Most applications will fit comfortably within this allowance, and as a developer you need not worry about memory at all.
In some cases, the resident processes in your dyno may reach or exceed that 512MB amount. Typically this is because of a memory leak in your application, in which case you may wish to use a memory profiling tool such as Oink for Ruby or Heapy for Python to track down the leak and fix it.
Dynos whose processes exceed 512MB of memory usage are identified by an R14 error in the logs. Though this does not terminate the process it is a warning of deteriorating application conditions as memory used above 512MB will go into swap, which can substantially degrade dyno performance.
If the memory size keeps growing until it reaches three times (512MB x 3 = 1.5GB) its quota, the dyno manifold will restart your dyno with an R15 error.
The dyno manifold is a distributed, fault-tolerant and horizontally scalable execution environment for your application's dynos. It manages a nearly infinite number and diversity of programs via the the process model in a completely hands-off and maintenance free fashion.
The dyno manifold restarts all your app's dynos whenever you create a new release by deploying new code, changing your config vars, or changing your add-ons. You can watch this happen in realtime via watch heroku ps in one terminal while pushing code or changing a config var in another.
Dynos are cycled at least once per day, or whenever the dyno manifold detects a fault in the underlying hardware and needs to move your dyno to a new physical location. Both of these things happen transparently and automatically on a regular basis and are logged to your application logs.
If your app has only a single web dyno running, it will idle out - irrespective of the number of worker dynos. You have to have more than one **web** dyno to prevent idling.
Apps that have scaled the number of web dynos (dynos running the web process type) so that only a single web dyno is running, will have that web dyno idled out after one hour of inactivity. When this happens, you'll see the following in your logs:
2011-05-30T19:11:09+00:00 heroku[web.1]: Idling
2011-05-30T19:11:17+00:00 heroku[web.1]: Stopping process with SIGTERM
When you access the app in your web browser or by some other means of sending an HTTP request, the routing mesh will signal the dyno manifold to unidle (or "wake up") your dyno to run the web process type:
2011-05-30T22:17:43+00:00 heroku[web.1]: Unidling
2011-05-30T22:17:43+00:00 heroku[web.1]: State changed from created to starting
This causes a few second delay for this first request. Subsequent requests will perform normally.
Apps that have more than 1 web dyno running are never idled out. Workers dynos are never idled out.
If a dyno's resident process crashes, either during start-up or during regular operation, the dyno manifold will immediately attempt to restart the dyno. If it crashes again, it will be subject to a ten-minute cooldown period until it restarts. (You can always manually restart it with the heroku restart command.)
Applications with multiple running dynos will be more redundant against failure. If some dynos are lost, the application can continue to process requests while the missing dynos are replaced. Typically, lost dynos are replaced immediately, but in the case of a catastrophic failure, it can take some time.
Dynos execute in complete isolation from one another, even when on the same physical infrastructure. This includes both dynos in the process formation and dynos run as one-off admin processes with heroku run. This provides complete protection from other application processes, or even system-level processes, consuming all available resources and rednering your application un-manageable.
The dyno manifold uses a variety of technologies to enforce strict dyno isolation, most notably LXC for subvirtualized resource and process table isolation, independent filesystem namespaces, and the pivot_root syscall for filesystem isolation. These technologies ensure security and guarantee resources such as CPU and memory in Heroku's multi-tenant environment.
Each dyno gets its own ephemeral filesystem, with a fresh copy of the most recently deployed code. During the dyno's lifetime its running processes can use the filesystem as a temporary scratchpad, but no files that are written are visible to processes in any other dyno and any files written will be discarded the moment the dyno is stopped or restarted.
When running multiple dynos, apps are distributed across several nodes in the dyno manifold. Access and routing to individual dynos is always controlled by the routing mesh, and goes through Heroku's public IPs.
As a result, dynos don't have static IP addresses. While you can never access a dyno directly by IP, it is possible to originate outgoing requests directly from a dyno. However, do not count on the dyno's IP being static. We actively monitor our grid, and frequently move dynos around to ensure optimal reliability and performance.