{ | |
"id":"dbauser", | |
"uid":506, | |
"comment":"DBA User", | |
"shell":"/bin/bash", | |
"groups": [ | |
"sysadm", | |
"dba" | |
], | |
"ssh_key": "XXXXXXXXXX" |
First, you install ruby-build and chruby. ruby-build is a program that knows how to download and build different ruby versions. chruby manages $PATH
to control which ruby
gets invoked in your shell. They work completely independently.
sudo su
cd /usr/src
git clone https://github.com/sstephenson/ruby-build.git
cd ruby-build
./install.sh
cd -
# Goal: put a non-Rails-aware Ruby library using normal `require`s in | |
# lib/sim. Have it transparently reloaded between requests like Rails app | |
# code is. | |
# | |
# The code here goes inside of your configure block in | |
# config/environments/development.rb. There are two parts, commented inline. | |
# Reload code whenever the simulator changes. | |
config.watchable_dirs["lib/sim"] = [:rb] | |
config.watchable_files << "lib/sim.rb" |
The prep-script.sh
will setup the latest Node and install the latest perf version on your Linux box.
When you want to generate the flame graph, run the following (folder locations taken from install script):
sudo sysctl kernel.kptr_restrict=0
# May also have to do the following:
# (additional reading http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar )
sudo sysctl kernel.perf_event_paranoid=0
Here is a collection of tips and tricks I've picked up about doing performance analysis on Node. Included is a build script that should get a base install of Ubuntu fully functional and ready for all the things we'll be going through.
The script pulls a lot of code from the latest master
of each repository. So
it's possible that something may fail, but to date I haven't had any issues.
First, go ahead and run the script. Then go take a nice long break. It'll
Deepseek r1 says this
-
APFS Global Kernel Lock (vfs-layer lock):
- Not fully bypassed: Even with a RAM disk formatted as APFS, macOS's global I/O lock still technically exists. However, because RAM disk operations are orders of magnitude faster than disk I/O, contention for this lock is drastically reduced. This makes the lock effectively irrelevant for most workflows, as operations complete before significant contention occurs.
- Not the same as Linux: macOS lacks a true
tmpfs
equivalent, so while a RAM disk helps, it’s not as seamless as Linux’s in-memory filesystem.
-
RAM Disk Format:
- macOS RAM disks can be formatted as HFS+ or APFS. While APFS is the default, formatting as HFS+ might slightly reduce lock contention (though benchmarks vary). Either way, the speed of RAM mitigates lock-related bottlenecks.