Fullstaq Ruby: Ruby, optimized for production

by thunderbong • 5 years ago

232 86 5 years ago

rashkov2• 5 years ago

This is neat. There’s a good FAQ explaining, for instance, why they don’t upstream these changes to ruby core. https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...

carl_dr• 5 years ago

To clarify for casual readers who might not dig into that, it’s not that Fullstaq is refusing to contribute or that they are commercial. They say :

“There will be no paid version. Fullstaq Ruby is fully open source. It is also intended to be a community project where anyone can contribute. There are no monetization plans.”

Thought I would mention that in case the parent’s comment implied something different. It’s more that the core Ruby team are reluctant to.

rashkov2• 5 years ago

Yes thanks for clarifying

mberning• 5 years ago

Cool project. Not a big fan of the name. Kind of hard to sell to a sourcing team. If they called it “Enterprise Ruby” or something like that the conversation is going to be much easier.

sudhirj3• 5 years ago

Phusion Passenger (same team) has lots of enterprise offerings with very entierprisey names and prices.

bdcravens3• 5 years ago

Is it the same team? Obviously it's the same lead developer, but I"m unclear the distinction between Phusion and Fullstaq

pmontra• 5 years ago

Name taken, see http://www.rubyenterpriseedition.com/

jmcgough• 5 years ago

amazing, this hasn't been updated since ruby 1.8

bdcravens3• 5 years ago

Actually from the same developer. This project is actually under a different company; it's not clear why.

bdcravens3• 5 years ago

Fullstaq is a company.

https://fullstaq.com/

sudhirj3• 5 years ago

For those wondering why on earth this isn’t simply a contribution to Ruby, the FAQ has a really nice explanation - tldr is that this is a variant optimised for the very specific context of Linux, x86/64, server environments, with pre compiled and packaged binaries, with special memory allocators (jemalloc).

These changes are specific to this context and are unlikely to be accepted into the more generalised Ruby core.

Same team as Phusion Passenger, so excellent background.

joelbluminator9• 5 years ago

I'm not really buying the FAQ explanation, idk this feels too good to be true. Would have loved to see some core team discussion on this if there was one.

FooBarWidget22• 5 years ago

Author of Fullstaq Ruby here. There have been discussions. Discussions on jemalloc integration preceded Fullstaq Ruby for years. The bug tracker issue on the malloc_trim patch went stale. All this can be found on the issue tracker.

I also spoke to Matz during EuRuKo 2019. And this is the impression I got.

rurban• 5 years ago

Everybody can do it by themselves. Using jemalloc is trivial. Adding the malloc_trim() call to the full GC is trivial. The patches are open.

Why MRI ruby likes to keep unused memory pages around is only, that they don't like to add that compile-time option and probe for jemalloc. It's too trivial to worry

jashmatthews• 5 years ago

jemalloc isn’t a special allocator. It’s basically the FreeBSD default.

actually_a_dog• 5 years ago

I think this is interesting, but I'm wondering why there isn't a corresponding project for Python. It seems like people using Python could derive the exact same benefits, so, why doesn't the Python version exist of this project?

karlding2• 5 years ago

I'm wondering why there isn't a corresponding project for Python.

But there are various projects for Python.

For example, there's Pyston [0] which was started by Dropbox. Or Cinder [1] which was started by Facebook. Or PyPy [2].

[0] https://github.com/pyston/pyston

[1] https://github.com/facebookincubator/cinder

[2] https://www.pypy.org/

joelbluminator9• 5 years ago

Still, adoption of these solutions seems low (PyPy seems to be a JIT as well is it really a corresponding solution?). If it magically reduces memory by as much as 30%-50% why isn't adoption higher? In other words what are the drawbacks of doing this, there must be cons.

wokwokwok• 5 years ago

You understand this is mostly ruby using jemalloc and some other memory allocation tricks?

Support for doing this in python was added in PEP-445 (https://www.python.org/dev/peps/pep-0445/) and implementation details can be found here from 2013 (https://bugs.python.org/issue3329). For more info see: https://docs.python.org/3/c-api/memory.html

You can see some commentary on using malloc-trim here too -> https://www.softwareatscale.dev/p/run-python-servers-more-ef...

...long story short: basically, you can already, but it doesn't really make much difference for most workloads.

Or, if your question is, why doesn't python get optimisation love and become fast like the javascript runtimes?

dunno. I guess we just don't have any big FANG companies pouring money on that, because they don't have a use for a faster python. A faster python does not make numpy, tensorflow or pytorch run faster because those are not written in python.

So I guess, there's a lack of value-for-effort in trying to 'fix' the problem of 'pure' python being slow.

jsmeaton• 5 years ago

FYI Microsoft is funding Guido and a small team to specifically work on performance see https://m.slashdot.org/story/385526

rapsey• 5 years ago

Time spent on dealing with optimisations is un under counted productivity sink of using languages like Ruby/Python.

joelbluminator9• 5 years ago

Thank you wise one for showing us the light.

stanislavb• 5 years ago

Has anyone installed fullstaq ruby with ASDF?

FooBarWidget22• 5 years ago

Anyone who wants asdf support, vote for it here: https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...

sidcool2• 5 years ago

When I read fully open source, bells ring in my mind. I adopted Cypress. It advertised open source and community ethos. But when delved deep, it many basic features that were paid. They never advertised it well in documentation. Once bitten, twice shy

stepbeek2• 5 years ago

What features are you missing? I’ve never paid for cypress purely because it had what I wanted out of the box. Now I’m wondering if I’ve missed something.

sidcool2• 5 years ago

Mainly parallel tests run. They have very limited support for parallel tests in community version. We need to buy the Cypress dashboard license

FooBarWidget22• 5 years ago

Author of Fullstaq Ruby here. There are absolutely no paid features, nor plans to monetize. There are even enough reasons to not monetize.

See the FAQ: https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...

And the project vision, which is community-based: https://www.joyfulbikeshedding.com/blog/2020-05-15-why-fulls...

faebi• 5 years ago

Do you have any plans to support ruby-install and therefore chruby?

FooBarWidget22• 5 years ago

No. Only rbenv. Unless there's a lot of user request.

jbverschoor2• 5 years ago

I recently switched to asdf. Big time rbenv user, then added nodenv. I also needed multiple yarn versions. As asdf is based off / inspired by rbenv, it was an easy change.

FooBarWidget22• 5 years ago

Update: if you want asdf support, vote for it here: https://github.com/fullstaq-labs/fullstaq-ruby-server-editio...

jrochkind12• 5 years ago

It's possible you can already easily use with chruby by just pointing chruby at it? I haven't tried, I am interested if anyone wants to report back!

https://github.com/postmodern/chruby#rubies-1

(You don't need to use ruby-install with chruby, you can use whatever method of installing rubies you want. The chruby README even includes instructions for `ruby-build`. But normally whatever method you use, you install to `/opt/rubies` or `~/.rubies` which is where chruby will look. But fullstaq ruby insists on installing to it's own locations. But possibly chruby will be fine with that if you just tell it where that is... but you might need to do it for each ruby you install, which woudl be annoying. You could probably write a little bash shim which just checked the fullstaq install location for which rubies it had, and then just added them each individually?)

augstein• 5 years ago

Would be a perfect fit, if this was available on Heroku.

Memory bloat is a real problem, even for mid-size Rails apps.

But it might not be in their interest, if customers are suddenly able to downgrade to cheaper Dynos with less memory, so we‘ll see.

zrail• 5 years ago

You can run whatever you want in Heroku. Fork the official Ruby buildoack and teach it to install fullstaq, it's pretty easy to work on.

sealjam• 5 years ago

It does say there’s a heroku edition “coming soon”

wlll4• 5 years ago

You can already use jemalloc on Heroku, it's really simple, so this comment is about releasing memory back to the OS, the other headline feature of Fullstaq.

Memory bloat is a real problem, even for mid-size Rails apps.

Yes, but the solution isn't releasing the memory back to the OS, that's just papering over the cracks. If you're running (say) 10 Rails processes on a machine with 10 GB RAM, and particular request paths/background jobs whatever pushes the process size to 2 GB RAM size, you can release the memory back to the OS after you're done, but you still have the underlying problem which is the process gets to that size in the first place, and if all the processes hit 2GB at once, now you're 10 GB in debt, either in swap, or OOM errors.

The solution you should be looking for is installing something like Scout (or NewRelic, but IMO Scout is better for memory stuff), looking to see what is bloating the processes, and in 99% of the time fixing it using some the Rails' batch find methods (seriously, it's ActiveRecord objects 99% of the time, bonus points for in-memory CSV reading or write buffers).

Rails applications don't have to balloon in memory.

FooBarWidget22• 5 years ago

If you're running (say) 10 Rails processes on a machine with 10 GB RAM, and particular request paths/background jobs whatever pushes the process size to 2 GB RAM size, you can release the memory back to the OS after you're done, but you still have the underlying problem which is the process gets to that size in the first place, and if all the processes hit 2GB at once, now you're 10 GB in debt, either in swap, or OOM errors.

Fullstaq Ruby author here. I have done research on the memory bloat problem[1], and this statement is not true. With the way memory allocation in glibc's ptmalloc2 works, multithreaded processes can reach bloaty proportions even if they don't do much work. I started investigating this whole issue because I had a trivial Ruby HTTP proxy server: it had no reason to use 1.3 GB of memory, it doesn't do anything besides forwarding small requests. That's when I found that ~1 GB of that 1.3 GB of memory wasn't even due to anything that my app did by itself, but it's just how the memory allocator works.

[1] https://www.joyfulbikeshedding.com/blog/2019-03-14-what-caus...

jbotdev2• 5 years ago

Maybe I’m missing something, but it seems the only changes here over upstream are jamlloc and/or malloc_trim. I’m not as familiar with malloc_trim, but jemalloc is fairly trivial to setup without recompiling Ruby (using LD_PRELOAD), and there are even buildpacks for environments like Heroku. It seems like more time was spent on the marketing page than on the actual optimizations.

FooBarWidget22• 5 years ago

Here I explain why it can quickly become not so trivial: https://news.ycombinator.com/item?id=27872696

The goal of Fullstaq Ruby is to democratize the fight against Ruby memory bloat. Democratization means that as many people should be able to reap the benefits as possible. It's 2021 now, and expecting users to compile Ruby or Jemalloc from source is no longer realistic. Compiling anything is no longer a non-scary, low-friction thing to do.

wgjordan3• 5 years ago

The parent comment noted that using jemalloc for Ruby without compiling is already trivially easy, so the argument that 'compiling is hard' is irrelevant even if true.

The real argument is that installing jemalloc separately and running Ruby with an environment variable is too hard.

jbotdev2• 5 years ago

It seems like the main value-add of this project is building/packaging pretty much standard Ruby in a consistent way across many Linux distributions, which is something that’s been hard to come by. I would lean into that more than anything else.

IfOnlyYouKnew• 5 years ago

I don't know if 2021 is much different than, say, 2012, in that I don't mind compiling something as long as it works? I'm sure there are intricacies with ruby's configuration, specifically. And that you invested time and have a good understanding of it.

But I'm not convinced it's a product and not a service, or a task for someone on staff for larger organisations.

As but one thing: to be a product it needs to have some universal value for a significant chunk of scenarios (possibly with some configuration options). But at that point, it's not clear why it shouldn't be a contribution to the upstream project. Is there, possibly, an "Enterprise Edition" or "Cloud Deployment Pro Plan" in the works?

I'm also (and that's neither here or there but I can't help myself) not entirely sure how democracy got involved here. While the rule of law and a participatory citizenry do tend to lead to obvious benefits, "reaping" evokes a one-way process that is sorta antithetical to the cooperative nature of democracies? Dunno, maybe it's just me. It's also on some buzzword bingo cards, although I can't quite say in what specific context...

taf2• 5 years ago

At least 10 years ago it was normal or at least in my circles to always compile your own Ruby with all the production settings needed… jemalloc … we just build our own rpms and it’s pretty easy then to roll out upgrades too …

sprite• 5 years ago

Thanks I didn’t know this was possible. I’m currently running Ruby compiled with jemalloc in production on elastic beanstalk with a custom AMI. If I can swap back to their AMI and just use LD_PRELOAD it will make upgrades a lot easier.

rubyn00bie• 5 years ago

Is this like a fancy new modern version REE (Ruby Enterprise Edition)? It’s got that vibe.

Edit: yep, exactly that.

snowmaker• 5 years ago

Wow, I'm really excited about this. Running a large rails website, we spent egregious amounts of money getting EC2 instances with extra ram. If they can fulfill their promise of reducing memory usage by 50%, that'll save us tens of thousands of dollars.

Fullstaq Ruby: Ruby, optimized for production

Related Stories