Command Line
pry -r ./config/app_init_file.rb- load your app into a pry session (look at the file loaded by config.ru)pry -r ./config/environment.rb- load your rails into a pry session
Debugger
| redis-cli keys "*" | while read LINE ; do TTL=`redis-cli ttl "$LINE"`; if [ $TTL -eq -1 ]; then echo "$LINE" >> 123.txt; fi; done; |
| require "async" | |
| CONCURRENCY = 1000 | |
| ITERATIONS = 100 | |
| def work | |
| Async do |task| | |
| CONCURRENCY.times do | |
| task.async do | |
| sleep 1 |
Command Line
pry -r ./config/app_init_file.rb - load your app into a pry session (look at the file loaded by config.ru)pry -r ./config/environment.rb - load your rails into a pry sessionDebugger
| batches = Queue.new | |
| Order.select(:id).find_in_batches do |batch| | |
| batches << batch.map(&:id) | |
| end | |
| cpu_available.times do | |
| Thread.new do | |
| while(ids = batches.pop) | |
| pid = Process.fork do | |
| Sunspot.index! Order.includes(:product).find(ids) | |
| end |
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"]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
cribbed from http://pastebin.com/xgzeAmBn
Templates to remind you of the options and formatting for the different types of objects you might want to document using YARD.
| class ParseEntries | |
| def process(message) | |
| entry = JSON.parse(message.value) | |
| [entry] | |
| end | |
| end | |
| class CombineEntries | |
| def initialize | |
| @open_transactions = {} |
forked from https://gist.github.com/chetan/1827484 which is from early 2012 and contains outdated information.
Templates to remind you of the options and formatting for the different types of objects you might want to document using YARD.
First, add pry-rails to your Gemfile:
https://github.com/rweng/pry-rails
gem 'pry-rails', group: :developmentThen you'll want to rebuild your Docker container to install the gems