CODEWITHSUNDEEP
ruby-on-railsrubymemory-managementmemory-leakscarrierwave
dabrain34
dabrain34

Reputation: 39

Ruby on rails memory management

I'm implementing a ruby on rails server(Ruby 2.2.1 and rails 4.1.10) and I'm facing some memory issues where the server process (puma) which can take 500MB and more. Mainly when i'm uploading large file to the server, i'm getting this kind of value. I'm using carrierwave.

My question is related to the ruby management system and garbage collection. Seen that my server is dedicated to embedded system , i really need to cap or control the memory, my process is taking from the system.

Is there a way to see which objects (with its size) are still alive and should not? Is it right that the memory system in ruby does not retrieve back the free memory to the system if the memory is fragmented? Please help me to figure out whats goin on when my memory is larger than 150MB idle.

Stéph

Upvotes: 2

Views: 734

Answers (3)

Olivier
Olivier

Reputation: 696

It fact, in your case carrierewave gem itself seems to be the source of your issue. This gem seems to use the entire file to play with it and not chunks... So when your uploading large files you can easily hit the memory limit of your server.

This post seems to confirm what I'm saying: https://github.com/carrierwaveuploader/carrierwave/issues/413

What I can suggest in your case is to consider using direct upload on S3 to save your server from processing the upload by doing it in background directly on Amazon servers.

I'm not very familiar with carrierwave but this gem should do the trick: https://github.com/dwilkie/carrierwave_direct

I don't know if it could be a valid solution for you, but regarding your issue it seems to be your best alternative.

Hope it helps :) !

Upvotes: 0

dabrain34
dabrain34

Reputation: 39

I guess my problem is not related to the way GC is starting because if i ask for a manual garbage collection gc.start, i dont get back my memory. Maybe i'm having a memory leak somewhere but i would like to find a way to track it.

Upvotes: 0

Olivier
Olivier

Reputation: 696

After reading a lot of posts talking about that problem, it seems that the real cause come from the Ruby GC, which is consuming a lot of server memory and causing a lot of server swapping since version 2.1.x .

To fix those performance issues, I just set RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR to a value around 1.25. You can play with that setting to find the best value for your environment.

FYI my app is running with Ruby 2.1.5 on Heroku Cedar 14 and it worked like a charm.

Hope it helps :)

Upvotes: 2

Related Questions