dhh

ruby '2.7.1'

gem 'rails', github: 'rails/rails'
gem 'tzinfo-data', '>= 1.2016.7'  # Don't rely on OSX/Linux timezone data

# Action Text
gem 'actiontext', github: 'basecamp/actiontext', ref: 'okra'
gem 'okra', github: 'basecamp/okra'

# Drivers

Rajeshr34

cd ~
apt-get install libfontenc1 xfonts-75dpi xfonts-base xfonts-encodings xfonts-utils openssl build-essential libssl-dev libxrender-dev git-core libx11-dev libxext-dev libfontconfig1-dev libfreetype6-dev fontconfig -y
#https://github.com/wkhtmltopdf/wkhtmltopdf/releases 
#replace arch
wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.5/wkhtmltox_0.12.5-1.bionic_amd64.deb
dpkg -i wkhtmltox_0.12.5-1.bionic_amd64.deb
apt --fix-broken install

badboy

#!/usr/bin/env ruby
# encoding: utf-8

require 'memory_profiler'

gem 'redis', ENV['RVERSION']
require 'redis'

puts Process.pid
puts Redis::VERSION

HoneyryderChuck

# chat.rb
require 'sinatra/base'
# this also loads celluloid io, let's keep that in mind
require 'celluloid/current'
require 'reel'

# The chat server, an IO Event Loop held by the actor
# Collects connections (Reel Event Streams)
# 
# Contrary to EventMachine, there is no event callback for

chrisseaton

wvengen

Finding a Ruby memory leak using a time analysis

When developing a program in Ruby, you may sometimes encounter a memory leak. For a while now, Ruby has a facility to gather information about what objects are laying around: ObjectSpace.

There are several approaches one can take to debug a leak. This discusses a time-based approach, where a full memory dump is generated every, say, 5 minutes, during a time that the memory leak is showing up. Afterwards, one can look at all the objects, and find out which ones are staying around, causing the

vkostyukov

API	Status Codes
[Twitter][tw]	200, 304, 400, 401, 403, 404, 406, 410, 420, 422, 429, 500, 502, 503, 504
[Stripe][stripe]	200, 400, 401, 402, 404, 429, 500, 502, 503, 504
[Github][gh]	200, 400, 422, 301, 302, 304, 307, 401, 403
[Pagerduty][pd]	200, 201, 204, 400, 401, 403, 404, 408, 500
[NewRelic Plugins][nr]	200, 400, 403, 404, 405, 413, 500, 502, 503, 503
[Etsy][etsy]	200, 201, 400, 403, 404, 500, 503
[Dropbox][db]	200, 400, 401, 403, 404, 405, 429, 503, 507

ChuckJHardy

class MyJob < ActiveJob::Base
  queue_as :urgent

  rescue_from(NoResultsError) do
    retry_job wait: 5.minutes, queue: :default
  end

  def perform(*args)
    MyService.call(*args)
  end

brianhempel

require "net/http"

def start_server
  # Remove the X to enable the parameters for tuning.
  # These are the default values as of Ruby 2.2.0.
  @child = spawn(<<-EOC.split.join(" "))
    XRUBY_GC_HEAP_FREE_SLOTS=4096
    XRUBY_GC_HEAP_INIT_SLOTS=10000
    XRUBY_GC_HEAP_GROWTH_FACTOR=1.8
    XRUBY_GC_HEAP_GROWTH_MAX_SLOTS=0

krasnoukhov

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 this to your Sidekiq configuration:

if ENV["PROFILE"]