Ruby


EuRuKo 2019 was lots of fun

EuRuKo 2019 – the largest Ruby conference in Europe, took place on the 21st and 22nd of June. I gave a talk on the 21st about what causes Ruby memory bloat (where I also reported new findings since I first blogged about the issue), as well as about Fullstaq Ruby. Fullstaq Ruby is a server-optimized Ruby distribution that's faster, uses less memory, and is easier to security-patch thanks to being distributed via RPMs and DEBs.

Read more »

What causes Ruby memory bloat?

Ruby apps can use a lot of memory. But why? Various people in the community attribute it to memory fragmentation, and provide two “hacky” solutions. Dissatisfied by the current explanations and provided solutions, I set out on a journey to discover the deeper truth and to find better solutions.

Read more »

Why Ruby app servers break on macOS High Sierra and what can be done about it

People who have upgraded to macOS High Sierra and who are using a preforking app server such as Puma or Unicorn (with the right settings), may have noticed this error:

objc[81924]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

This cryptic error is triggered under the following conditions:

  1. You are using Unicorn with preload_app, or Puma in cluster mode, or iodine in prefork mode, or Passenger in smart spawning mode.
  2. And you are using MRI.
  3. And your application uses a gem that is either directly or indirectly linked to the macOS Foundation framework.

This error is caused by changes in how fork() behaves in High Sierra. This article covers:

  • What is this and why did Apple change it?
  • How are the Puma, Unicorn and Passenger authors responding to this?
  • What can you do about it, and do you need to do anything at all?
  • What should the wider Ruby ecosystem do?

Read more »