- TypeScript 1.5 http://www.typescriptlang.org/
- WebPack http://webpack.github.io/
- awesome-typescript-loader https://github.com/s-panferov/awesome-typescript-loader
- DefinitelyTyped http://definitelytyped.org/
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"]
Every time my test cluster is going down, I was struggeling with etcd autodiscovery failing. This looks probably familiar to you:
systemd[1]: Starting etcd...
systemd[1]: Started etcd.
etcd[3066]: [etcd] Apr 9 08:31:42.512 INFO | Discovery via https://discovery.etcd.io using prefix /<TOKEN>.
#!/bin/bash | |
function tmux_web { | |
SESSION_NAME=$1 | |
#echo "Create.." | |
tmux new -s $SESSION_NAME -n editor -d | |
#echo "Creat first pane (editor).." | |
tmux send-keys -t $SESSION_NAME 'vim' C-m | |
#echo "Run vim in first pane.." | |
tmux new-window -n console -t $SESSION_NAME |
#### Tmux configuration file #### | |
# \; - used for separating commands on binding | |
# Right colors for tmux | |
set -g default-terminal 'screen-256color' | |
# remapping command prefix to "Ctrl + a" and unbind "Ctrl+b" | |
set -g prefix C-a | |
unbind C-b |
set :branch do | |
tag = ENV['TAG'] || Capistrano::CLI.ui.ask("What tag do you want to deploy? ") | |
if tag.empty? | |
logger.important 'tag is emtpy, exiting' | |
exit | |
else | |
tag | |
end | |
end |
data:text/html, <style type="text/css">#e{position:absolute;top:0;right:0;bottom:0;left:0;}</style><div id="e"></div><script src="http://d1n0x3qji82z53.cloudfront.net/src-min-noconflict/ace.js" type="text/javascript" charset="utf-8"></script><script>var e=ace.edit("e");e.setTheme("ace/theme/monokai");e.getSession().setMode("ace/mode/ruby");</script> |
Below are the actual files we use in one of our latest production applications at Agora Games to achieve zero downtime deploys with unicorn. You've probably already read the GitHub blog post on Unicorn and would like to try zero downtime deploys for your application. I hope these files and notes help. I am happy to update these files or these notes if there are comments/questions. YMMV (of course).
Other application notes:
- Our application uses MongoDB, so we don't have database migrations to worry about as with MySQL or postgresql. That does not mean that we won't have to worry about issues with the database with indexes being built in MongoDB or what have you.
- We use capistrano for deployment.
Salient points for each file:
-- show running queries (pre 9.2) | |
SELECT procpid, age(clock_timestamp(), query_start), usename, current_query | |
FROM pg_stat_activity | |
WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' | |
ORDER BY query_start desc; | |
-- show running queries (9.2) | |
SELECT pid, age(clock_timestamp(), query_start), usename, query | |
FROM pg_stat_activity | |
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs