How to clear memory cache in Linux

Linux 에서 캐시된 메모리를 어떻게 정리할 수 있을까? 결론적으로 세 가지 방법으로 캐시된 메모리 삭제가 가능하다.

1. 페이지 캐시 해제

2. 해제 가능 오브젝트(dentry, inode) 해제
– dentry에 대해서는 여기(http://unix.stackexchange.com/questions/4402/what-is-a-superblock-inode-dentry-and-a-file)를 참조하자.

3. 해제 가능 오브젝트 + 페이지 캐시 해제

아래는 캐시된 메모리 해제와 관련한 자세한 내용이다.(https://www.kernel.org/doc/Documentation/sysctl/vm.txt)

drop_caches

Writing to this will cause the kernel to drop clean caches, as well as
reclaimable slab objects like dentries and inodes.  Once dropped, their
memory becomes free.

To free pagecache:
	echo 1 > /proc/sys/vm/drop_caches
To free reclaimable slab objects (includes dentries and inodes):
	echo 2 > /proc/sys/vm/drop_caches
To free slab objects and pagecache:
	echo 3 > /proc/sys/vm/drop_caches

This is a non-destructive operation and will not free any dirty objects.
To increase the number of objects freed by this operation, the user may run
`sync' prior to writing to /proc/sys/vm/drop_caches.  This will minimize the
number of dirty objects on the system and create more candidates to be
dropped.

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.

You may see informational messages in your kernel log when this file is
used:

	cat (1234): drop_caches: 3

These are informational only.  They do not mean that anything is wrong
with your system.  To disable them, echo 4 (bit 3) into drop_caches.

실제로 캐시를 줄이는 명령어는 원하는 모드에 따라 아래와 같은 방식으로 입력하면 된다.

$ echo 1 > /proc/sys/vm/drop_caches
$ echo 2 > /proc/sys/vm/drop_caches
$ echo 3 > /proc/sys/vm/drop_caches

다음은 테스트 결과이다. 확실히 캐시된 메모리가 줄어드는 것을 확인할 수 있다.

 

root@mywork:~# free -m
total       used       free     shared    buffers     cached
Mem:          7703       3618       4084        433        309       1239
-/+ buffers/cache:       2069       5633
Swap:         7627          0       7627

root@mywork:~# echo 1 > /proc/sys/vm/drop_caches

root@mywork:~# free -m
total       used       free     shared    buffers     cached
Mem:          7703       2700       5003        432          0        641
-/+ buffers/cache:       2058       5644
Swap:         7627          0       7627

 

참조: http://unix.stackexchange.com/questions/58553/how-to-clear-memory-cache-in-linux

What’s my epitaph

정말 영감받는 글귀를 보았다.

자신의 묘비명은 무엇인가… 하는 내용이었는데.. 뭔가.. 울컥하는 느낌이 있었다.

자기보다 훌륭한 사람들을 곁에 모으는 기술을 가졌던 사람이 여기 잠들다.

단순한 글귀이지만, 나에게는 “다른 사람을 인정할 줄 알고, 그들을 존중하고, 진심으로 대했던 사람” 이라는 느낌으로 다가온다..

좋다. 좋은 글귀다.
앞으로 마음속으로 계속 생각하며 살아야겠다. 🙂

why ps is wrong?

오늘 kldp 에 ps로 메모리를 확인하려고 하는데 잘 안된다는 질문 내용을 봤다.

https://kldp.org/node/152025

답글을 작성하다가 재미있는 내용을 알게 되어 이곳에도 같이 담아둔다.

 

질문 내용

프로그램 안에서 10 바이트씩 malloc 으로 메모리를 할당했습니다.
그리고 ps -eo user,size,cmd 명령으로 메모리 증가량으로 확인하려고 했지만 전혀 메모리 증가가 안되네요.

왜 그런거죠?

답변

두 가지 이유가 있습니다.

1. 확인하고자 하시는 메모리 증가량이 너무 작습니다.

man ps 에서 size 항목을 찾아봤는데 따로 단위는 안나오네요.
하지만 테스트 해보니 단위가 1K 였습니다.
프로그램을 수정해서 한번에 1M 씩 증가하도록 해봤는데, 증가량이 확인되네요.
할당하는 메모리 크기를 1M 단위로 하신다면 쉽게 증가 내역을 확인하실 수 있습니다.

2. ps 명령은 정확한 메모리 량을 확인하기에는 부족한 유틸리티 입니다.
출처 : http://stackoverflow.com/questions/131303/how-to-measure-actual-memory-u…

ps 명령은 사실 어플리케이션에서 사용하는 정확한 메모리 양을 나타내지 않습니다. 단지 예약된 메모리 양을 나타낼 뿐입니다.
달리 말하면 때에 따라(커널 레벨에서 사용되는 페이지가 공유 되거나 할 경우)변동될 소지가 있다는 것입니다. (예를 들면 여러개의 쓰레드나 동적 라이브러리를 사용하는 경우가 있습니다.)

그리고 만약 정확한 메모리 크기를 확인하고자 하신다면 다른 프로그램을 사용하셔야 합니다. valgrind 가 대표적이죠. 주로 메모리 누수 탐지에 사용되지만 메모리 사용량을 확인할 수도 있습니다.

————————————————————————————

실제로 위에 인용한 스택 오버플로우의 내용 말고도 ps 는 메모리 사용량을 확인하는데 부족하다는 내용의 많은 양의 문서를 확인할 수 있었다.

정확한 메모리 사용량을 확인하고자 한다면, 다음의 링크에 소개된 프로그램을 이용하자.

http://www.binarytides.com/linux-command-check-memory-usage/

how to use git branch

오늘 git 브랜치 관련한 특강을 받았다… 그동안 git 을 몰라도 너무 모르고 있었다는 생각이 들었다.

 

브랜치 생성

레드 마인을 사용하고 있다면 feature, bug 와 같이 생성된 이슈에 맞춰 새롭게 브랜치를 생성하자.
생성하는 브랜치 이름은 “feature/이슈번호-이슈제목”, “bug/이슈번호-이슈제목” 와 같이 지정하면 좋다.
브랜치 이름에는 브랜치를 생성한 이유가 나타나야 한다.

그리고 하나의 브랜치에서 너무 많은 작업들을 하려고 하는 것은 좋지 않다.

너무 큰 크기의 수정 작업은 잘게 잘라서 여러 개의 브랜치에서 나눠할 수 있도록 하자.

 

커밋

한번에 하나의 내용만을 지정하여 커밋을 하자.

Fixed a lot.

– Fixed many.

과 같은 내용은 정말로 좋지않다!!!(실은 내가 자주 그랬다.)

Fixed memory leak.

– valgrind test complete.

위와 같은 커밋을 보면 메모리 누수를 valgrind 를 통해서 잡았다는 것을 알 수 있다.
그러면 당연히 수정 내용에는 메모리 할당/해제와 관련된 내용만 있을 것이다.
만약 메모리 할당/해제가 아닌 다른 기능 추가와 같은 내용들이 들어가게 되면 이는 커밋의 내용과는 맞지 않는 것이다.
당연히 코드를 리뷰하는 사람의 입장으로서는 의문이 생기고 수정 내용이 이해가 안되게 된다.

각각의 브랜치는 저마다의 정확한 목적을 가지고 있어야 한다.
그리고 각각의 커밋은 커밋의 정확한 이유가 있어야 한다.

 

코멘트

소스를 수정한 구체적인 이유를 적자.

예를 들어 다음과 같은 예를 들어보자.

Added snom phone functionality

– Added snome specification

Added: snom_function.c, snome_function.h, aastra.c

위와 같은 커밋에서 코멘트는 snom phone 기능을 추가했다고 하였다. 하지만 추가된 소스코드에는 aastra.c 파일이 껴 있다.
이상한 일이다. snom 폰과 aastra 폰은 서로 다른 전화기 이기 때문이다.
잘못된 커밋 옵션으로 파일이 추가된 것일지도 모른다.
즉시 aastra.c 파일을 추가한 이유를 물어볼 수 있다.

Why text messages are limited to 160 characters?

출처 : http://latimesblogs.latimes.com/technology/2009/05/invented-text-messaging.html

단순 문자 메시지 전송 서비스(SMS)의 경우, 한번에 최대 160 바이트까지 전송이 가능하다. 영문 기준 160 자, 한글 기준 40 자 이다.

왜 이런 제한이 생겼을 까?

그 이유는 독일의 Friedhelm Hillebrand 사람 때문이라고 한다.

Friedhelm Hillebrand 는 타자기를 사용하면서 자신의 문장에 들어가는 글자 수를 세기 시작했다. 그리고 나중에는 “160자(물음표, 마침표 등 모든 기호를 포함)면 대부분의 생각과 의견을 나타낼 수 있다”라는 결론을 도출했다.

이는 Hillebrand의 매직 넘버라고 불리었으며 훗날의 SMS 문자 메시지의 길이를 정하는데 영향을 미치게 된다. 더 가깝게는 초기 트위터의 140자 제한까지 영향을 미치게 되었다.(140 메시지 + 20 아이디 표시).

참고로 이 이론이 나온때는 1985년 이었다.

160자로 대부분의 생각과 대화를 표현할 수 있다는 생각은 그 당시에는 합당했을 것이다.

단순한 메시지나 대화를 나타내기에는 적당할 것이다.

하지만 여러가지 인용과 링크 정보, 다른 사람들의 생각등.. 대화와 의견을 표출하는 방법이 옛날과는 많이 달라졌다는 것이 문제일 것이다.

즉…. 160자는… 짧다…!