[parfe]

>GitLab has memory leaks. These memory leaks manifest themselves in long-running processes, such as Unicorn workers. (The Unicorn master process is not known to leak memory, probably because it does not handle user requests.)

>To make these memory leaks manageable, GitLab comes with the unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to do a memory self-check after every 16 requests. If the memory of the Unicorn worker exceeds a pre-set limit then the worker process exits. *

I know this is a Rails issue, but I cannot believe this is still a problem. I remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel, more than a decade ago. They were obviously incorrect. Did the community simply give up on fixing the problem?

* https://docs.gitlab.com/ee/administration/operations/unicorn...

[obl]

I have no idea about either ruby or rails but since ruby is a managed language this kind of issues seem like they should be pretty easy to debug ?

After all, if the gc is not freeing the memory then it must know a reachable path to it so the blame should be easy to assign.

Does ruby not have any good heap profiling tool ?

[skrebbel]

I don't know anything about Rails but most memory leaks in managed languages are stuff like lists growing infinitely large, parts of them pointing to data that is no longer relevant. Think badly implemented caches, stuff like that.

If you have enough not-perfectly-cleanly-separated layers of data management interacting, then this gets hard to debug pretty fast.

[briandear]

Why are they still using unicorn over Puma? That’s one question. Using unicorn killer is the sign of some bad engineering. It’s the equivalent of restarting your server every hour.

[sytse]

We are planning to start using multi threading and Puma so we can reduce the memory requirements of GitLab. The last time we shipped that we had to revert due to hard to diagnose errors. We're taking a more incremental approach now.

[qop]

Were you under the impression that Rails has a functioning dev community?

I am very familiar with the rubyverse, and boy do I got news for you.

Rails is to Ruby as the Big Dig is to Boston.

But it's hard to get Rails devs to admit it. They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top.

I used to think Zed was a dramatic weenie. Then I got a bit deeper in Rails to learn how to pursue better exploits. And deeper. And deeper. And finally I just hit a point where I just wasn't willing to work on RoR-related gigs.

Convention over configuration is one of those ideas that goes great on paper. And then you start in on some buzzwords and fancy lingo, it's the bread and butter of selling to project managers. But there is a point where CoC breaks down at a technical level, and that point is literally the first moment you come across something difficult to express

Rails is weak in doing things ANY other way than the Rails way, and what developers do (and it's not their fault) is using their creativity and ingenuity to solve the problem. I believe this is why metaprogramming in Ruby has such a vocal backing, because there are millions of shims holding up millions of Rails' shitty choices that depend on method_missing fuckery or string-based define_method gadgets. In the spirit of what it means to solve hacker-ish problems, it's great fun to program like that for a while, and then a year or two down the line you look at that shit and it can really break you down. Good developers mistake themselves for bad developers because of this, to be honest.

Zed's probably had the idea to write an entire book of how insanely FUCKED Rails actually is, but to make the book plausibly thorough would mean a human being being exposed to far more stupidity than modern science can safely treat for. It'd be dangerous to have that much stupid intake just for a book.

That unicorn-worker-killer gem is a perfect caricature of the kinda problem-solving you run into with Rails. Let it die a horrible death, restart that shit with some logic to let it keep dying predictably.

That technique, multiplied by every component in the system, multiplied by every developer on the team, multiplied by MVC requiring developers to have to know too broadly the system they're working on, multiplied by however many years and Rails versions the project has somehow survived, you approach something I can only imagine is quite similar to what hell must be.

[artursapek]

I spent 3 years working on a Rails app and it was enough to make me swear off Rails for the rest of my life. I think the Rails dev community has good intentions, and the design of Rails is actually pretty nice. The problem in my opinion is more with Ruby, and human laziness. Ruby lets programmers do absolutely anything they can think of no matter how unexpected or un-intuitive it will be to their colleagues. Combined with the rigid conventions of Rails' design, this inevitably leads to a maintenance disaster with people, like you say, getting too creative.

Refactoring a large Ruby on Rails codebase is basically impossible. There's no compiler to help you along; hell the code is evaluated lazily. So instead of refactoring, people monkey-patch their problems away. It's horrible, really really horrible.

I'm now getting flashbacks to trying to understand how files get loaded in that codebase... I need a drink

[terracatta]

> They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top

I think this is a dangerous line of thinking. This crosses the line of being productively critical of a language or a framework into actually attacking people.

By promoting this line of thinking, you increase the tolerance of this kind of attack.

People arrive at their personal choice of language and framework as a function of their environment, their education, their first job, what's popular at the time, and myriad of other factors.

I am sure you have preferences for languages and frameworks, and I'm sure there are other people who don't agree with them. Do you want those people giving you reasoned arguments about why you should change your preferences or, do what you did, make allusions that you are so irredeemably stupid that you physically exhale shoddy code?

[mikekchar]

My day job is working on Rails apps (most of the time anyway -- we have a diverse infrastructure). I'm not a big fan of Rails architecture and struggle to communicate to others why I think the "Rails Way" is not necessarily a good way. But these things are hard to swallow, especially if you haven't seen anything else before.

However, I have a special dislike for "convention over configuration". What that really means is: You must write code my style. As there is no configuration, it will be difficult to discover what that means by reading the code. You must study and memorise the one true way. If you deviate from it, strange things will probably happen and it will be your fault for not doing it my way.

To be fair, Rails documentation is really very good. Also, this is a selling point for the framework. If you give no choices then everybody must do it the same way. Even if that way is stupid. You can hire a whole bunch of people who "know rails" and they can struggle along and make progress. You don't have to trust them with decisions because the important decisions were already made for them.

I've had a wide and varied career before doing this work. It's hard for me accept "because it's the Rails Way" to questions like "Why are we doing this when it is causing problems?" I don't mind people making mistakes as long as it is not a thoughtless mistake. "I thought this would work, but I was wrong", is a wonderful sentence in my book. Unfortunately that's the kind of action that many programmers are dissuaded from taking -- instead they are encouraged to do it the "Rails Way".

Lots of beginning programmers also prefer it this way. When you are first starting out (and... well... even when you've been doing it for a couple of decades) it's hard to know which way is better. You might even have a preference, but then struggle greatly when someone asks "Why is that better". Especially beginning programmers often get stuck without knowing any way to accomplish something. In those cases, the "Rails Way" is extremely comforting. 1) It's a way. 2) It will probably work (at least grossly) 3) Famous people say it's good, so it's very, very comforting to agree. People entrenched in the community reinforce each other until it seems practically impossible that there might be a better way. But they may not have looked.

Of course Rails is not the only "Way" out there that espouses these ideas. It's just a currently popular one. What's really at fault is the "convention over configuration" attitude -- Don't think; just do it my way. I hate that.

[keybits]

Still lots of love for Rails in the HN community on this recent thread: https://news.ycombinator.com/item?id=17355187

[TheAceOfHearts]

I love Rails for certain projects, but it's definitely true that at a certain point things start to break down. Maintaining a large complex application with Rails is not fun at all. ActiveRecord is amazing, until it's not.

IMO, you can still learn tons of great practices with Rails, and for certain projects I still think it's a great choice... But you have to know when to drop it and move on to more robust solutions.

Like most engineering tools, it makes certain tradeoffs, and you have to know how to pick the right one for your job.

[9935c101ab17a66]

I am no expert at all (a current comp sci student), but when I read this line in the unicorn-killer explanation I lol'd:

> This is a robust way to handle memory leaks

Seriously wow.