Tag: heroku

• ---

  Memory Leak Whack-a-Mole

  
  October 27, 2016
  

  ⊕
  https://www.flickr.com/photos/tpapi/2765541278Memory leaks happen. They shouldn’t, but you just can’t squash enough of them. Or the leak is so slow that it takes hours to manifest. The trouble with memory leaks is that they are permanent for the life of a process. Once a process has expanded its VSZ, there’s no way in Unix to shrink it. So your process starts to bloat, eventually your servers page and thrash. Performance tanks. Then your pager starts going off and there goes your beauty sleep.

• ---

  Zero Downtime Migrations

  
  August 15, 2015
  

  For any sufficiently large application, you want to minimize interruptions to service while deploying new code. This is especially challenging for migrations on Heroku and other Platforms-as-a-Service, where you have a Catch-22 problem; you want to run your migrations, first, but you can’t run them until you’ve deployed the migrations to production. Usually, at this point, your new migration-dependent features are in the deploy, too. So when your application restarts, and the migration hasn’t run, yet, your poor application will trip some exceptions, and perhaps, create problems for your users. Of course, you could put the app into maintenance mode, but that creates more downtime for your users.

• ---

  The Slow Road

  
  June 1, 2014
  

  Once a week, we run a query on our production system that takes a very long time to complete. Invariably, it times out because the default settings on Heroku are (quite reasonably) for web / API interactions; anything longer than 30 seconds is too long and the connection should be closed to let other requests through. How do you get around this, then? You could set up your database.yml file so that you connect to your production database from a developer workstation. This is actually quite useful, but opens up a hellacious security hole. Let’s not get started about the consequences of accidentally running rake db:drop:all! Moreover, you want your system to be automated as much as possible, and that means running your tasks on a Heroku instance. Fortunately, with a little hackery, you can modify the connection timeout settings within your application. Do this carefully, and make sure that it can not leak into your running web application dynos.

• ---

  Deploy Strategies for HerokuSan

  
  May 12, 2012
  

  If you look at the network graphs of heroku_san on github, you'll see a number of branches where the only change is the deletion of the following line from the deploy task:

• ---

  Dry DevOps with HerokuSan

  
  March 25, 2012
  
  1. How many times (each day) have you typed this at your console?
     git push heroku master and then forgotten to run
     heroku run rake db:migrate --app yellow-snow-3141 or
     heroku ps:restart
  2. Does your script support a multi-stage environments?
  3. Do you remember how to get to the application's console process?
  4. Is your application's configuration consistent across all stages?
  5. Are you deploy scripts tested?