Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I spent two weeks hunting a memory leak in Ruby (2015)

be9.io

Post reply on HN
Print view View original

31–40 of 71 posts

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#31

Post by oldmanjay »

mikekchar wrote: post #28
kyledrake wrote: post #25

Interesting post, but I did want to chime in quickly and say that it's pretty absurd to only have 1GB for a web application in 2016, even for a small one. This is why I've been dismissive of using Heroku for my projects, even though I run a lean stack. They have higher RAM options, but they are incredibly expensive. For the cost of a 14GB Heroku Dyno, I can buy a dedicated server off ebay with 32GB ECC every single m…

> it's pretty absurd to only have 1GB for a web application in 2016 While I don't for a minute doubt what you say, as an old guy, the absurdity of 1GB being insufficient for serving up web pages hits me pretty hard.

Web applications don't just serve up web pages, which puts you in the unenviable position of being dismissive or ignorant about the topic.

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#32

Post by kyledrake »

mikekchar wrote: post #28
kyledrake wrote: post #25

Interesting post, but I did want to chime in quickly and say that it's pretty absurd to only have 1GB for a web application in 2016, even for a small one. This is why I've been dismissive of using Heroku for my projects, even though I run a lean stack. They have higher RAM options, but they are incredibly expensive. For the cost of a 14GB Heroku Dyno, I can buy a dedicated server off ebay with 32GB ECC every single m…

> it's pretty absurd to only have 1GB for a web application in 2016 While I don't for a minute doubt what you say, as an old guy, the absurdity of 1GB being insufficient for serving up web pages hits me pretty hard.

Our main proxies (that do the majority of the heavy lifting over here) run nginx and use, what, 50MB tops? If even? I throw them on $5/mo VPS instances and they just blast out IO without any problems.

But nginx was carefully written in C over the course of many years, with a general goal of hauling IO and static data around from other systems. Which is all you really need for web pages, in the end. Solved one thing and holy crap they did it well.

It's the business logic side of the web development world where things get nasty. The tradeoff is you get a giant chest of libraries for solving any stupid problem you want. I didn't have to for example figure out how to do IDN encoding for domain validation. You throw enough of that crap together in a single process and things start to get nasty. But how long would I have spent carefully writing all of it in C? Let's just say I'd be out looking for another job.

Worth the tradeoff, IMHO, but I think with projects like Crystal (https://crystal-lang.org) in the future we will discover we can get pretty close to both in the end. That combined with Moore's law and I think we'll be good to go.

Assuming, of course, that cloud providers don't artificially restrict available RAM through economic constraint (know the true costs - demand better!).

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#33

Post by kristianp »

busterarm wrote: post #30
mrud wrote: post #29

Earlier quoted context omitted.

There is no xmalloc in the libc.

Okay, interesting. I guess I've seen it before, so I didn't think it was Ruby-specific, but I also haven't had to do that kind of programming in a very super long time. Publib then? I'm finding this when I search: http://man.cx/xfree(3) http://man.cx/publib(3) Also, are you sure? I see xmalloc in glibc all over the internet...

edit: actually xmalloc and xfree are defined as

#define xmalloc ruby_xmalloc #define xfree ruby_xfree

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#34

Post by haimez »

scott_s wrote: post #12
rgtk wrote: post #4

There is no reason for using native extensions in scripting languages like Ruby when program load is pretty low (especially when they are used for performance reason, not binding). Great insight, though. Author described this experience as it was a great venture... in hindsight I suppose :-)

Your criticism really applies to the gem authors, which to me, does not make sense. If I, as a library developer, want my library to be used on the critical path in heavy-load situations, and the library is for a language like Ruby, I'm going to figure out which part of my library are the performance critical parts, and implement them in a native language.

You would think that you (in this case, "you" == "average library author in the ruby ecosystem") would, but you won't. I'm fairly confident the problem is similar, but likely worse in the javascript ecosystem.

Necessity is the mother of invention, and when you're the first person to notice a memory leak, you're on your own.

Both ecosystems tout the low barrier to entry as a great benefit, but memory leaks, mostly benign inefficiencies, and poor algorithmic efficiency becomes at least par for the course if not a crippling liability when reality hits your application like a freight train (or say a 2 order-of-magnitude spike).

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#35

Post by snissn »

kyledrake wrote: post #25

Interesting post, but I did want to chime in quickly and say that it's pretty absurd to only have 1GB for a web application in 2016, even for a small one. This is why I've been dismissive of using Heroku for my projects, even though I run a lean stack. They have higher RAM options, but they are incredibly expensive. For the cost of a 14GB Heroku Dyno, I can buy a dedicated server off ebay with 32GB ECC every single m…

Out of curiosity, albiet slightly off topic can you share an example server that you'd buy? I'm totally in the aws kool aid soup and would love to see some reasonable examples of how to buy server alternatives

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#36

Post by busterarm »

kristianp wrote: post #33
busterarm wrote: post #30

Earlier quoted context omitted.

Okay, interesting. I guess I've seen it before, so I didn't think it was Ruby-specific, but I also haven't had to do that kind of programming in a very super long time. Publib then? I'm finding this when I search: http://man.cx/xfree(3) http://man.cx/publib(3) Also, are you sure? I see xmalloc in glibc all over the internet...

edit: actually xmalloc and xfree are defined as #define xmalloc ruby_xmalloc #define xfree ruby_xfree

That's actually fascinating. I wonder if anyone has background on this...any comments I see are in Japanese.

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#37

Post by snissn »

mikekchar wrote: post #28
kyledrake wrote: post #25

Interesting post, but I did want to chime in quickly and say that it's pretty absurd to only have 1GB for a web application in 2016, even for a small one. This is why I've been dismissive of using Heroku for my projects, even though I run a lean stack. They have higher RAM options, but they are incredibly expensive. For the cost of a 14GB Heroku Dyno, I can buy a dedicated server off ebay with 32GB ECC every single m…

> it's pretty absurd to only have 1GB for a web application in 2016 While I don't for a minute doubt what you say, as an old guy, the absurdity of 1GB being insufficient for serving up web pages hits me pretty hard.

Interpreted languages can have pretty high memory overhead. Let's say we have a page in python or php or ruby or whatever, and it needs to fetch 1,000 rows from a database (100 things here, 20 things there, whatever). Each row in the database can be turned into an object several times, one from the model, one from the controller, one for the template/view. On top of that, each object is a composite key/value object of let's make up 10 fields, so that's 20 PyObjects or whatever. In Python an empty PyDict uses up 280 bytes. sys.getsizeof({}). so 1,000321*280 = 17.64MB. That's just a back of the envelope theoretical minimum, include bad coding (for another few multiples), pages that require more data (analytics/stats/reporting pages), and concurrency and you can get up there!

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#39

Post by flukus »

kyledrake wrote: post #25

Interesting post, but I did want to chime in quickly and say that it's pretty absurd to only have 1GB for a web application in 2016, even for a small one. This is why I've been dismissive of using Heroku for my projects, even though I run a lean stack. They have higher RAM options, but they are incredibly expensive. For the cost of a 14GB Heroku Dyno, I can buy a dedicated server off ebay with 32GB ECC every single m…

>Interesting post, but I did want to chime in quickly and say that it's pretty absurd to only have 1GB for a web application in 2016

That really depends on a lot of things. For a simple web app with a couple of users, 1GB should be overkill.

Re: How I spent two weeks hunting a memory leak in Ruby (2015)

#40

Post by eudox »

busterarm wrote: post #36
kristianp wrote: post #33

Earlier quoted context omitted.

edit: actually xmalloc and xfree are defined as #define xmalloc ruby_xmalloc #define xfree ruby_xfree

That's actually fascinating. I wonder if anyone has background on this...any comments I see are in Japanese.

Replacing malloc/calloc/free etc an application-specific xmalloc/xcalloc/xfree is seemingly a fairly common pattern. There's one example in libiberty[0] (-liberty, get it?) where, for instance, the return value of malloc is checked for NULL and the program terminates if so.

[0]: http://www.delorie.com/gnu/docs/gcc/libiberty_5.html

Post reply on HN