Other popular posts
At Nodejitsu we use a standard 256mb container image for our Individual Plans. For most personal applications in steady-state this is more than enough. But there's one common one-time exception: deployment itself. We understand it has been a major deploy issue affecting Individual Plan customers (Business Plans have control over the container sizing). If you are a user trying to use a popular framework like
sails.js or even a
hood.ie app, you may have run into an error on deploy with something corresponding to an ENOMEM. That's Error No Memory, Holmes! (cue sound of gears grinding to an teeth-ripping halt).
Well last week we did a slipstream update to all of our servers that fixed this issue. Before I go into how we fixed this bug that left you head-scratching, let me give you some more context on how the deployment process works.
Deploying an app
When we deployed our new architecture last year we went in depth on how things changed but I will give you a brief summation here. When you deploy your application, we go through three steps.
- Upload your application
- Build dependencies of your package
- Deploy your application by executing a command over SSH
There are a couple relevant memory-related parameters in this process that would affect the deployability of your application.
- Size of your original application
- Size of the installed dependencies of your application
All applications for Individual Plan users and many applications for our Business Plan users run in our cloud run on 256MB RAM SmartOS Zones. This memory cap is what has been the limiting factor as we are executing a node process
solenoid in order to..
- Fetch and unpack your prebuilt tarball
- Set proper permissions on the machine
- Start your application and wait for it to listen on a port
There can be nice chunk of memory still allocated even after a successful untar due to the download itself, the rest of procedure (on many occasions) would be the one to cause the
ENOMEM. I'll spare you my personal hair-pulling frustration on this problem, except to say that I may need Rogaine. I was trying to look for any possible optimization in order to make it work. Even after implementing streaming untar, it still wasn't enough.
Solution: Execute two commands
It turns out the solution to this problem was more simple than we expected. Instead of relying on a single process to execute the complete procedure needed to start your app, we split it up into 2 commands,
solenoid download and
solenoid start. By taking advantage of the brilliant
ssh2 module and the newfound simplicity given by
sequest, our deploy scripts are able to execute two commands in series using the same ssh connection! We pushed the effective snapshot ceiling up a bit.
By using two commands, the deploy has more room to maneuver. If the snapshot was successfully extracted, the deploy will now succeed. This raises the snapshot size that can be deployed from ~30mb up to ~72mb (not including dependencies)!
So if you've smacked into this limit with
hood.ie or anything that seemed to push the memory limit on deploy, please give it another try! If you're already on one of our Business Plans you can always increase the amount of RAM your drone uses with
$ jitsu cloud joyent us-east-1 --ram 512 # or --ram 1024