brodock

blueprint:
  name: Wake-up light alarm with sunrise effect
  description:
    "A wake-up light alarm with a brightness and color temperature sunrise
    effect. Note: not manually executable!"
  domain: automation
  input:
    light_entity:
      name: Wake-up light entity
      description:

brodock

My largest Sidekiq application had a memory leak and I was able to find and fix it in just few hours spent on analyzing Ruby's heap. In this post I'll show my profiling setup.

As you might know Ruby 2.1 introduced a few great changes to ObjectSpace, so now it's much easier to find a line of code that is allocating too many objects. Here is great post explaining how it's working.

I was too lazy to set up some seeding and run it locally, so I checked that test suite passes when profiling is enabled and pushed debugging to production. Production environment also suited me better since my jobs data can't be fully random generated.

So, in order to profile your worker, add the sidekiq_profiler.rb (below) to your project

Adjust number of jobs you want your worker to process before you have heap dumped.
Run a sample worker: PROFILE=1 sidekiq -C config/sidekiq.yml and wait for jobs to be processed.

brodock

require 'thwait'

# Synchronous hand-off between two threads.
# Both threads will block until a transfer is successful.
class Rendevous
  def initialize
    @mutex = Mutex.new
    @send_flag = ConditionVariable.new
    @recv_flag = ConditionVariable.new
    @container = []

brodock

require 'ostruct'
class JsonStruct < OpenStruct
  def initialize(hash = nil)
    @table = {}
    @hash_table = {}

    return unless hash
    hash.each do |k, v|
      recursive_initializer(v) if v.is_a?(Array)