Why top and ps not showing the same cpu result

왜 ps 와 top 은 서로 다른 cpu 사용률을 보여주는 것일까? 결론부터 이야기하면, top 과 ps 는 서로 다른 명령어이다.

top 은 우리가 흔히 생각하는 cpu 사용률을 보여주는 것이 맞지만, ps 는 약간 다른 부분을 보여준다. 다음은 ps 명령어의 man page 의 일부분이다.

CPU usage is currently expressed as the percentage of time spent running during the entire lifetime of a process.  This is not ideal, and it does not conform to the standards that ps otherwise conforms to.  CPU usage is unlikely to add up to exactly 100%.

즉, ps 명령어는 프로세스가 동작한 전체 시간에서의 cpu 점유율을 나타낸다는 것이다. 따라서 지정된 시간 동안에서의 cpu 점유율을 보여주는 top 과는 서로 다른 결과를 보여줄 수 밖에 없는 것이다.

top 은 모니터링, ps 는 스냅샷으로 생각을 하면 이해가 쉬워진다.

참조: http://unix.stackexchange.com/questions/58539/top-and-ps-not-showing-the-same-cpu-result

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

Avast infection blocked

얼마전, 내 홈페이지와 wiki 사이트 등에 접속이 막힌다는 이야기를 들었다.

정확히는 Avast 에서 블럭 처리한다는 이야기였다.
때문에… Avast 에 메일을 보냈다. 정상적인 홈페이지니 false positive 오류인 것 같다고..

그랬더니, 오늘 답장을 받았다.

Hello,

Any domain hosted on afraid.org can be used by other persons for dns hosting without your control.
It happened for your domain, it was misused for malicious purposes – in that case, when nobody has control on subdomains of domain (DNS hijacking), we block the whole domain in order to protect our users.
For you, the solution is most probably only changing the dns hosting and letting us know later.

Best regards,
Valerij Medviď
Virus analyst

내용인즉, 내가 사용하고 있는 DNS 서비스(afraid.org) 를 사용하게 되면 DNS higacking 의 위험성이 있기 때문에 내 도메인 전체를 블럭처리를 한 것이란다..
afraid.org 란, DNS 서비스를 무료로 이용하는 대신의 자신의 도메인의 2차 도메인부터를 무료로 개방하는 오픈 도메인 사이트이다.

…. 무료이고 사용도 깔끔해서 이용했던 건데.. 이런 문제가 생긴것이다.. 에효.

DNS 하이잭은 또 뭐람? 공부할꺼리가 생겨버렸네..

Private cloud – Owncloud

라즈베리 파이를 구입하고 이를 개인용 클라우드 시스템으로 사용하고자 했었다.

적당한 개인용 클라우드 시스템으로 Owncloud 를 선택해서 라즈베리 파이에 설치한다음 몇번의 테스트를 했었다.

클라우드 시스템을 구축하려고 꽤 많은 투자를 했었는데(외장형 하드디스크, 확장 USB 케이블..등등) 결국 라즈베리 파이로 클라우드 시스템은 불가능하다는 결론을 내렸다.

문제는 라즈베리 파이 성능이었다.

너무 느렸다.
총 용량 2.1 G, 파일 갯수 15,000 개 기준으로 최초 동기화시 20시간 이상이 걸리는 것으로 확인되었다.
그리고 너무 오랜 동기화 시간에 지쳐서 해당 디렉토리를 동기화 취소를 하고 Owncloud 시스템 상에서 삭제를 했는데, 이 역시 시간이 너무 오래 걸렸다.
처음에는 Owncloud 프로그램의 문제로 짐작하고 이것저것 다른 부분들 맞춰주기위해 설정등을 조합해서 맞춰 봤는데, 모두 허사였다.

그러다가 어제 개인용 랩탑에 Owncloud 를 설치해서 테스트를 해보았다.

놀랄만한 속도였다.
20시간 이상이 걸리던 것이 30분 정도밖에 안 걸렸다.(용량 30 G, 파일 갯수 30,000 개)

아직 불필요한 패키지 삭제와 오버클럭 등, 개선할 부분이 많이 있었지만, 도저히 비교할 수 없는 성능의 차이였다.

사실 문제는 파일 갯수가 너무 많았다는 것이었다.
파일 갯수가 적고, 단지 용량만이 많은 경우(예를 들면 버추어 박스 이미지 같은 것들)라면 라즈베리 파이에 Owncloud 설치가 굉장히 매력적일 수도 있다. 하지만 사진, 소스파일 과 같이 개개의 용량이 작고 갯수가 많은 환경이라면 강력 비추천이다.

결론: 클라우드 시스템으로 관리되는 파일 갯수가 많은 사람이라면, 라즈베리 파이-owncloud 는 피하는 것이 좋다.

Raspberry pi with owncloud

라즈베리 파이를 사면서부터 이걸로 무엇을 해볼까 고민했었는데, 일단은 개인용 클라우드 시스템을 만들기로 했었다.

가이드와 여러 자료들을 살펴가며 열심히 서버를 설정했다.

이윽고, 모든 설치가 정상적으로 설치되고 사용하려고 하는데…

한가지 문제점이 있었다.
최초 클라우드 시스템 동기화를 위해 내 파일들을 업로드를 하는데 시간이 너무 오래 걸리는 것이었다.
하루는 밤새도록 켜놓고 있었는데, 20M 업로드를 했다.

이대로는 못쓰겠다 싶어서 설치 과정중에 문제가 있을까 싶어 몇번이고 재설치를 반복했다.
또한 클라우드 시스템에 붙이기 위해 새로 구입한 외장형 하드디스크도 문제가 있는 것 같아 그 부분도 같이 검증했다.
하드디스크가 좀 걱정이 되었으나 다행히 그부분은 문제가 아니었다.

무엇이 문제였을까…
현상은 파일 업로드가 지나치게 느리다는 것, 클라이언트쪽 실패 메시지를 확인해보니 단지 “Internal Error”라고만 나왔다.

결국 서버쪽 에러 로그를 확인하고난 뒤에서야 원인을 파악할 수 있었는데, 이유인 즉 Sqlite 때문이었다.

Sqlite는 DB Input/Ouput 시 DB 전체에 데이터베이스 Lock 을 걸어버린다.
보통은 이 속도가 금방이기 때문에 순식간에 지나가는데, 이 경우는 무엇때문인지는 모르겠으나,오류 발생 이후 업로드 재시도까지 굉장한 시간이 걸리는 것 같았다.

아무튼 문제는 Sqlite 로 진단하고 Mysql 로 변경해서 설치를 진행한 후, 정상적으로 작동한 것을 확인했다.

 

IMG_20150118_215845