Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Okay, I found the answer. I am leaving my other answer up because that information was very difficult to gather, it is related, and it could help someone else searching for a related issue. </p> <p>Your problem, however, appears to be due to the fact that Ruby actually does <strong>not</strong> release memory back to the Operating System once it has acquired it. </p> <blockquote> <p>Memory Allocation</p> <p>While Ruby programmers do not often worry about memory allocation, sometimes the following question comes up:</p> <p>Why did my Ruby process stay so big even after I’ve cleared all references to big objects? I’m /sure/ GC has run several times and freed my big objects and I’m not leaking memory.</p> <p>A C programmer might ask the same question:</p> <p>I free()-ed a lot of memory, why is my process still so big?</p> <p>Memory allocation to user space from the kernel is cheaper in large chunks, thus user space avoids interaction with the kernel by doing more work itself.</p> <p>User space libraries/runtimes implement a memory allocator (e.g.: malloc(3) in libc) which takes large chunks of kernel memory2 and divides them up into smaller pieces for user space applications to use.</p> <p>Thus, several user space memory allocations may occur before user space needs to ask the kernel for more memory. Thus if you got a large chunk of memory from the kernel and are only using a small part of that, that large chunk of memory remains allocated.</p> <p>Releasing memory back to the kernel also has a cost. User space memory allocators may hold onto that memory (privately) in the hope it can be reused within the same process and not give it back to the kernel for use in other processes. <a href="http://blog.rubybestpractices.com/posts/ewong/005-Avoiding-system-calls.html">(Ruby Best Practices)</a></p> </blockquote> <p>So, your objects may very well have been garbage collected and released back to Ruby's available memory, but because Ruby never gives back unused memory to the OS, the rss value for the process remains the same, even after garbage collection. This is actually by design. According to <a href="http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/">Mike Perham</a>:</p> <blockquote> <p>...And since MRI never gives back unused memory, our daemon can easily be taking 300-400MB when it’s only using 100-200.</p> <p>It’s important to note that this is essentially by design. Ruby’s history is mostly as a command line tool for text processing and therefore it values quick startup and a small memory footprint. It was not designed for long-running daemon/server processes. Java makes a similar tradeoff in its client and server VMs.</p> </blockquote>
    singulars
    1. This table or related slice is empty.
    1. POFinding the cause of a memory leak in Ruby
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USJoe Edgar
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COA simple test shows that Ruby does release memory (at least as far as the rss value measures). Run this (forgive the lack of whitespace): `def report; puts 'Memory ' + \`ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"\`.strip.split.map(&:to_i)[1].to_s + 'KB'; end; report; big_var = " " * 10000000; report; big_var = nil; report; ObjectSpace.garbage_collect; sleep 1; report`; The result is: Memory 7132KB Memory 17100KB Memory 17100KB Memory 7340KB
      singulars
      1. PO
      1. USnp_
    2. COHmm, the results of this seem odd and inconsistent. When using 1.9.3-p429 I get the following results: `At Program Start: Memory 51408KB; After Creating big var: Memory 61176KB; After setting big var to nil: Memory 61176KB; After Garbage Collection: Memory 61176KB;` Using Ruby 2.0.0-p195 I get these results: `At Program Start: Memory 80772KB; After Creating big var: Memory 90540KB; After setting big var to nil: Memory 90540KB; After Garbage Collection: Memory 90612KB; `
      singulars
      1. PO
      1. USJoe Edgar
    3. COWith 1.9.3p484 I get similar results as my run with 2.0.0-p247 -Memory 9364KB, Memory 19136KB, Memory 19136KB, Memory 9368KB. In my production app I can definitely see the RSS size go up and then back down when dealing with any requests other than the ones that trigger the CSS parser. Perhaps your second link is only talking about older versions of Ruby or are referring to a different measurement (virtual memory size?). Also, http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-752
      singulars
      1. PO
      1. USnp_
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload