Re: fsck memory leak

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Theodore Ts'o wrote on 12/04/2015 08:58 PM:
On Fri, Dec 04, 2015 at 06:53:53PM +0100, U.Mutlu wrote:
Please send the output of cat /proc/meminfo (a) before running fsck,
(b) after running fsck, and then (c) after running "echo 3 >
/proc/sys/vm/drop_caches".

Just tried it out.
Doing "echo 3 > /proc/sys/vm/drop_caches" solves the problem.

There's no problem then --- except in your understanding of how
Linux's memory management system works.

Linux keeps data that was read from disk in its buffer and page cache,
because there is always a chance that data could be needed again.  So
although it looks like free space is being consumed by the buffer and
page caches, if those pages are clean (not dirty; if they were
modified, we've gotten around to writing the modified data back to
disk) and inactive (not installed in some process's page table, such
that the page is visible in some process's virtual address space),
even though those pages aren't counted as "free" memory, it can be
instantly reused for something else.

So doing something like "echo 3 > /proc/sys/vm/drop_caches" is
actually a _bad_ thing, since it means you are throwing away data that
could be used to avoid blocking waiting for disk I/O to complete.
However, if it helps satisfy some system administrator's insecurity
because they are looking at this field:

           total      used      free    shared  buff/cache   available
Mem:        15G      4.4G  ==> 4.5G <==  392M        6.4G         10G
Swap:        0B        0B        0B

when they should be looking at *this* field:

           total      used      free    shared  buff/cache   available
Mem:        15G      4.4G      4.5G      392M        6.4G    ===> 10G <===
Swap:        0B        0B        0B

It's just being silly.

Yes, after doing the "echo 3 > /proc/sys/vm/drop_caches", you would
see this instead:

           total      used      free    shared  buff/cache   available
Mem:        15G      4.1G       10G      390M        927M         10G
Swap:        0B        0B        0B

But reducing the size of buff/cache is not a win!  If you suddenly
need the memory because you suddently started some memory hog such as
Eclipse, the system will automatically reclaim the clean and inactive
pages for use by the new memory user.  But until then, why not keep
the cache pages around just in case they are needed?

Regards,

						- Ted


I think it's a double-edged sword: if user has less memory then
the integrated caching will IMO degrade the performance.

Btw, why does my "free" command not have the "available" column?
Or did you use a different tool for the above outputs?



--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux