Skip Navigation
Show nav
Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
Hide categories

Categories

  • Heroku Architecture
    • Compute (Dynos)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Developer Tools
    • Command Line
    • Heroku VS Code Extension
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery & Integration (Heroku Flow)
    • Continuous Integration
  • Language Support
    • Node.js
      • Troubleshooting Node.js Apps
      • Working with Node.js
      • Node.js Behavior in Heroku
    • Ruby
      • Rails Support
      • Working with Bundler
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Background Jobs in Python
      • Python Behavior in Heroku
      • Working with Django
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Working with Maven
      • Working with Spring Boot
      • Troubleshooting Java Apps
    • PHP
      • PHP Behavior in Heroku
      • Working with PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
      • Migrating to Heroku Postgres
    • Heroku Key-Value Store
    • Apache Kafka on Heroku
    • Other Data Stores
  • AI
    • Model Context Protocol
    • Working with AI
    • Heroku Inference
      • AI Models
      • Inference Essentials
      • Inference API
      • Quick Start Guides
    • Vector Database
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
      • Single Sign-on (SSO)
    • Private Spaces
      • Infrastructure Networking
    • Compliance
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
  • Language Support
  • Ruby
  • Troubleshooting Ruby Apps
  • Tuning glibc Memory Behavior

Tuning glibc Memory Behavior

English — 日本語に切り替える

Last updated February 12, 2025

Table of Contents

  • When to tune MALLOC_ARENA_MAX
  • What value to choose for MALLOC_ARENA_MAX

Application maintainers may tune application performance and memory use by adjusting the MALLOC_ARENA_MAX environment variable.

Recent versions of glibc use multiple memory pools that malloc can allocate memory from. Especially for threaded programs, using multiple memory pools can speed up memory allocation (be reducing locking) and improve overall performance. See this article for details on the glibc malloc arena implementation.

With some memory allocation patterns, this performance improvement can come at the cost of somewhat greater app memory consumption. This may especially be the case for programs that create and destroy many threads and allocate lots of memory in those threads.

As of September 24th, 2019 - when you deploy a new application to Heroku we will default your MALLOC_ARENA_MAX=2. You can check if this value is set for your app by running

$ heroku run bash
~$ env | grep MALLOC_ARENA_MAX
MALLOC_ARENA_MAX=2

If this is not set on your app by default, you can manually set it:

$ heroku config:set MALLOC_ARENA_MAX=2

When to tune MALLOC_ARENA_MAX

If your application has MALLOC_ARENA_MAX=2 set but has plenty of memory to spare, you may be able to see small gains in response time by increasing this value. While testing was performed a long time ago, since then there have been numerous reports of the positive effects of this setting compared to it’s a relatively small downside.

  • Malloc Can Double Multi-threaded Ruby Program Memory Usage
  • Taming Rails memory Bloat

If your application does not use MALLOC_ARENA_MAX=2 look out for R14 errors or increased memory consumption reported in application metrics. Setting this value to 2 may help reduce memory consumption for your application.

What value to choose for MALLOC_ARENA_MAX

The glibc default number of memory pools on 64bit systems is 8 times the number of CPU cores (the number of CPU cores seen by dynos on Heroku varies with dyno type).

If your app doesn’t perform well with the default glibc setting, you can adjust the behavior by changing the MALLOC_ARENA_MAX configuration variable for the app.

$ heroku config:set MALLOC_ARENA_MAX=2

If you don’t want to apply the setting to the entire app, but only to a particular process type showing adverse memory behavior, you can prepend your Procfile command with the environment setting: sidekiq: env MALLOC_ARENA_MAX=2 bundle exec sidekiq

Choosing a value MALLOC_ARENA_MAX is generally a tradeoff between performance and memory consumption. Not setting MALLOC_ARENA_MAX gives the best performance, but may mean higher memory use. Setting MALLOC_ARENA_MAX to “2” or “1” makes glibc use fewer memory pools and potentially less memory, but this may reduce performance. Based on the testing we’ve done, we recommend a value of “2” if you want to try to reduce app memory use.

If your application is still memory-constrained please see the article on R14 - Memory Quota Exceeded in Ruby (MRI) which contains ideas for how to reduce your memory usage.

Keep reading

  • Troubleshooting Ruby Apps

Feedback

Log in to submit feedback.

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices