Heroku

How It Works

Dynos

Last Updated: 03 December 2011

architecture dyno memory

Table of Contents

See How it Works, an illustrated tour of Heroku’s architecture and how dynos fit into the picture.

A dyno is a single process of any type running on the Heroku platform. This can 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 as dynos.

Dyno Features

  • Elasticity: The number of dynos allocated for your app can be increased or decreased at any time - without any server provisioning.

  • Intelligent routing: The routing mesh tracks the location of all web dynos and routes HTTP traffic to them accordingly.

  • Process management: Each dyno process is monitored for responsiveness. Misbehaving dynos are taken down and new dynos are launched in their place.

  • Distribution and redundancy: Dynos are distributed across a distributed execution environment known as the dyno manifold. An app configured with two web dynos is running two processes, as you’d expect, but each process is running in a separate physical location. If a machine goes down, 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.

Dyno Concurrency and Scaling

The number of dynos allocated to an app directly affects the app’s maximum concurrency and request throughput. Adding more web dynos allows you to handle more concurrent HTTP requests, and more workers will let you process more jobs in parallel.

Read more about scaling your dynos on Heroku.

Dyno Memory Behavior

Each dyno gets 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, 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 that exceed 512MB of memory usage will display an R14 error in the logs, like this:

2011-05-03T17:40:10+00:00 heroku[worker.1]: Process running mem=528MB(103.3%)
2011-05-03T17:40:11+00:00 heroku[worker.1]: Error R14 (Memory quota exceeded)

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:

2011-05-03T17:40:10+00:00 heroku[worker.1]: Process running mem=2565MB(501.0%)
2011-05-03T17:40:11+00:00 heroku[worker.1]: Error R15 (Memory quota vastly exceeded)
2011-05-03T17:40:11+00:00 heroku[worker.1]: Stopping process with SIGKILL

Frequently Asked Questions

How do I change the number of dynos or workers?
  1. with the slider on the resources page for your app,
  2. using the heroku command-line client
  3. directly through the API.

Either way, changes are almost instant – it only takes a few seconds to deploy your requested number into the dyno grid. Dynos and workers are prorated to the second, so if you want to experiment with different configurations, you can do so and only be billed for actual seconds set. Remember, it’s your responsibility to set the correct number of dynos & workers for your app.

How many requests can a dyno serve?

A single dyno can process one request at a time; for a “typical” app, this translates to somewhere between 10 and 50 dynamic requests per second. Your app’s overall performance translates directly to how many requests your dynos will be able to serve.

How much does a dyno cost?

Dynos cost $0.05 per hour, prorated to the second. For example, an app with four dynos is charged $0.20 per hour for each hour that the four dynos are running.

Pricing is based on calendar time. If you set your app to four dynos, you will be charged $0.20 per hour regardless of the traffic your site serves during that time.

Each application receives 750 free dyno hours per month. For example if you have 1 web dyno running for all of April, and a worker dyno running half the time you would have 330 dyno-hours billed that month or $16.50 (720 web dyno hours + 360 worker dyno hours - 750 free dyno hours).

See the pricing page for an estimate monthly cost under various configurations.

What is dyno idling?

Apps that have only 1 web dyno will be idled out after a period of inactivity. The web dyno will be shut down. When a request comes in to an idled app your web dyno will be automatically spun back up, causing a few second delay for this first request. Subsequent requests will perform normally.

Apps that have more than 1 web dyno are never idled out. Workers dynos are never idled out.