1

The free command output of my server is currently like below:

# free -m
             total       used       free     shared    buffers     cached
Mem:           995        780        205          0         49        599
-/+ buffers/cache:        140        854
Swap:            0          0          0

We know that the dd application generally employs the page cache to accelerate the file access.

After issuing the command:

dd if=/dev/zero of=2.txt bs=1M count=10

The following output shows that the page cache has increased by 10M or so.

# free -m
             total       used       free     shared    buffers     cached
Mem:           995        790        215          0         49        599
-/+ buffers/cache:        140        854
Swap:            0          0

The preceding output is normal.

Then I ran 

sync
command that will sync the content in page cache to hard disk along again with a 
free -m
command.

Nothing changed as follows. Is it related to the write back mechanism? which stipulates the page cache won't be reclaimed despite the sync command's execution, unless this part of page cache is being changed.

Or the page cache won't be recycled at all until the kernel parameter /proc/sys/vm/drop_caches gets modified?

# free -m
             total       used       free     shared    buffers     cached
Mem:           995        790        205          0         49        599
-/+ buffers/cache:        140        854
Swap:            0          0          0

If so, how much is the maximum size the cache in 'free -m' can reach? Is there any kernel parameters controlling it? Thanks.

Jepsenwan
  • 170
  • 3
  • 12

1 Answers1

2

dd does not directly use page cache, it does I/O which is automatically cached.

Dropping a cache simply because something was committed is inefficient. The next read would need to come from the underlying device, which probably is hundreds to thousands of times slower than RAM.

Expect that caches will use up to nearly all of unused RAM. Count it is as free memory, caches are among the first to be reclaimed if programs allocate memory.

Do not use /proc/sys/vm/drop_caches in production operation, it does not help. From Documentation/sysctl/vm.txt

This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system.

Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended.

The sysctl documentation for vm does list a few tuning parameters to control the virtual memory subsystem, including dirty page behavior and minimum free. I do not recommend changing them until you understand in detail the benefits of doing so. Until then use the defaults or pre-defined tuned profiles.

Community
  • 1
John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thanks. I noticed if I issue the dd command again with the same arguments，it wont get the cached number that's returned by free command increased despite the execution of sync command. Is this because the page cache hit？ – Jepsenwan Jul 12 '17 at 03:55
  • Yes. Caches are not dropped until there is not enough free memory for other demands. – John Mahowald Jul 12 '17 at 10:47
  • Thanks John. An extra question.Under any circumstance the hugepage will be employed as page cache? For instance, in system running a Oracle database. – Jepsenwan Jul 13 '17 at 10:13
  • Huge pages cannot be used as as page cache or a few other uses, no. Which means tuning for databases involves sizing pages correctly. This is a broad topic and really a different question, I recommend reading a tuning guide for that database. – John Mahowald Jul 13 '17 at 13:15
  • Thanks John. I just realized that the hugepage is much bigger than page in disk. Besides. Hugepage is pined in main memory. So it wont have anything to do with page cache. – Jepsenwan Jul 13 '17 at 13:35