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

SIP/RTP initiation bug

늘 있는 일이었지만, 특별히 더 이상한 일이었다. 분명히 발생하는 장애였다. 하지만 늘 그랬듯이 불규칙적이었고, 재현이 불가능하였다.

사건의 발생은, 고객사 중 하나에서 “정상적으로 음성메시지를 남겨도, 실제로 음성 메시지를 플레이 할 때는, 아무 소리가 안난다”는 것이었다. 가볍게 생각했다. record 함수의 잘못된 사용이나, 녹음할 데이터가 없었거나….

 

일단, 로그 파일부터 확인했다.

/var/log/freeswitch/freeswitch.log

먼저 문제가 발생한 케이스를 추려내고, 그 다음, 정상적인 케이스의 로그를 비교해보았다. 모든 부분에서 같은 내용이었지만, 단 한곳 다른 부분이 있었다.

[DEBUG] switch_rtp.c:5617 Correct ip/port confirmed.

문제가 발생한 로그에서는 위의 라인이 빠져 있었던 것. 바로 freeswitch 소스 파일을 확인해보았다. 해당 로그 라인이 어떨때 나타나는 로그인지 확인했다. 해당 로그는 freeswitch 에서 RTP 패킷을 read 를 시작할 때, 나타내는 로그 중 하나였다. 즉, 문제가 되는 로그에서는 RTP read 시작 로그를 확인할 수 없었다.

이상했다. 왜냐하면 나머지 SIP 관련 로그들은 정상적으로 송/수신 했기 때문이다. 로그내용으로 확인할 수 있었다.

그리고 분석된 장애 내용은 실제로 사용자는 음성사서함 메시지를 남기려고 시도 했었지만 무슨일이에선지, 생성된 wav 파일 사이즈가 모두 44 바이트(wav header size)가 생성되는 현상이었다.

그리고.. 계속된 재현 실패.. 수십 차례에 걸친 다양한 테스트 케이스에도 재현에 성공할 수 없었다. 사실 44 byte가 녹음되는 현상은 몇개 찾을 수 있었다. 하지만 더 세밀한 분석 결과, 이번 장애와는 상관없는 다른 이유에서 발생한 것으로 결론이 난 것들이었다.

그러다가 겨우겨우 오늘 재현에 성공했다.

앞서 말했듯이, 장애는 불규칙적으로 발생하고 있었다. 하지만 그 중에서도 장애가 ‘자주’ 발생하는 고객사가 있었는데, 그 고객사의 전화번호를 이용해서 재현할 수 있었던 것이다.

우리회사는 덴마크에 있었고, 해당 고객사는 독일에 있었다. 덴마크에서 독일 고객사로 전화를 걸어 음성 메시지를 남기면 정상적으로 남길 수 있었다. 하지만 독일 전화번호를 이용하여 독일 고객사로 전화를 걸면 44 바이트의 음성 파일이 생성되는 것이었다.

좋다. 이제야 겨우 재현에 성공했다. 여기까지 도달하기까지 굉장히 많은 시간이 걸렸다(약, 2주일?)

아무튼 테스트를 진행했는데, 모든 서버에서 tcpdump 명령어를 이용하여 패킷을 캡쳐하고 해당 캡쳐 내용들을 비교했다. 분석된 내용은 독일 네트워크 어딘가에서 RTP 패킷을 차단하고 있었던 것. 왜 차단을 했을까? 열띤 토론끝에, 이런 현상은 비단 독일뿐 아니라, 다른 어느곳에서도 가능한 현상이라는 추측이 나왔다. 그래야만 그동안 발생했던 불규칙 장애에 대한 설명이 된다는 것이다.

결론적으로… 아직까지 장애는 진행중이다. 이제야 겨우 재현에 성공하고 문제의 실마리를 잡았기 때문이다. 그리고, 오늘로써 개발자(나)의 잘못이 아닌것으로 밝혀졌지만(ㅎㅎㅎㅎㅎ) 그것과는 별개로 굉장히 인상적인 장애였고, 장애 분석이었다.

왜냐하면, 오늘 네트워크 관리자, 개발자(나), 개발 선임, 컨설턴트 이렇게 4명이 모여 이런저런 토론을 하고, 구체적인 방법을 구상하고, 테스트를 했는데 굉장히 인상적이었기 때문이다.

 

결론은…혼자 끙끙 앓고 있던 2주일간의 고민이 한방에 해결되었다.  🙂

apache ssl enable problem

아파치에 ssl 설정을 하고 https 접속을 하려는데 다음의 오류가 나왔다.

Secure Connection Failed

An error occurred during a connection to pchero21.com. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

구글링을 해봐도 ssl 모듈을 활성화 시키라는 이야기만 나오고…. 단지 설정값을 이리저리 바꿔보고 테스트하는 삽질만 하고 있었다.

 

그러다가, 짚히는 부분이 있어서, ssl 인증서를 다시 만들고 테스트를 해봤더니 잘 되었다.

처음 SSL 인증서를 만들 때, 다음의 명령어를 사용했었다.

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout ./postfix.key -out ./postfix.crt

문제가 되었던 부분은 rsa:2048 부분이었다.

다음의 명령어로 다시 ssl 인증서를 만들고 설정하니 잘 되었다.

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:1024 -keyout ./postfix.key -out ./postfix.crt

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