Skip to content

Instantly share code, notes, and snippets.

View DCrow's full-sized avatar
:electron:
Working as always

Yaroslav Barkovskiy DCrow

:electron:
Working as always
View GitHub Profile

Proxmox VE tips

Just a somewhat chaotic list of personal Proxmox VE related tips/notes or interesting (to me) things I'm working on or experiment with.
Some of the things you see here are niche or purely experimental. I try to label them as such, but as always with random code snippets, make sure to review anything before running it in your own environment. Perhaps test in a virtual PVE first.

Please note that unless you see a shebang (#!/...) these code blocks are usually meant to be copy & pasted directly into the shell. Some of the steps will not work if you run part of them in a script and copy paste other ones as they rely on variables set before.
The { and } surrounding some scripts are meant to avoid cluttering your shell history with individual commands, etc. You can ignore them if you manually copy paste the individual commands.

Table of contents

@krasnoukhov
krasnoukhov / 2013-01-07-profiling-memory-leaky-sidekiq-applications-with-ruby-2.1.md
Last active September 28, 2025 09:53
Profiling memory leaky Sidekiq applications with Ruby 2.1

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"]