리눅스 CPU Load Average의 위험 범위는?

OS/Linux 2017. 5. 12. 15:54 Posted by 알 수 없는 사용자

http://amateurteamblog.tistory.com/112

에서 퍼온 글입니다



원본글 링크Understanding Linux CPU Load - when should you be worried?


위 글을 번역한 글입니다. 오역이 있을 수 있습니다.


이 포스트를 검색해 들어왔다면, 아마 Load average라는 개념에는 익숙할 것이다. 널리 알려진 바와 같이, Load average는 uptime이나 top 명령어를 쳤을 때 나타나는 세 실수 값으로, 실제 예는 아래와 같다.


load average: 0.00, 0.01, 0.05


대부분의 사람들이 load average의 개념을 다음과 같이 파악하고 있다. 세 숫자가 1분, 5분, 15분 동안 실행 대기 중인 프로세스의 평균 개수이며, 낮을수록 좋다는 것, 그리고 load average가 높으면 해당 머신이 과부하 상태라는 것 정도. 자, 그럼 load average의 한계 값은 얼마일까? 이른바 “좋은”, “나쁜” load average 값이란 어느 정도일까? 그리고 Load average에 대해서 살펴봐야 하는 사항에는 어떤 것이 있고, 이를 최대한 빨리 처리하려면 어떤 작업을 해야 할까?


우선, load average가 실제로 무엇을 의미하는지 살펴볼 필요가 있다. 문제를 단순화 해서, 싱글 코어 프로세서로 구동 중인 장비를 우선 생각해보자.


다리를 건너는 자동차를 예시로 들어보자.


싱글 코어 CPU는 1차선 도로와 같다. 어떨 땐 다리를 건너려는 차들이 많아 다리 위가 매우 혼잡할 것이다. 그럼 다리 위가 얼마나 혼잡한 지를 어떻게 수치로 나타낼 수 있을까? 제일 간단한 방법은 특정 시간 동안 얼마나 많은 차가 건너려고 대기 중인지 파악하는 것이다.


만약에 대기 중인 차가 없다면 바로 다리를 건널 수 있을 것이고, 대기 중인 차가 있다면, 당연히 기다려야 한다. 종합해보면 다음과 같은 정책을 쓸 수 있다.

  • 0.00은 도로 위에 아무런 차도 없다는 뜻: 사실 0.00부터 1.00까지는 대기 중인 차가 없다는 뜻으로, 새로 건너려는 차는 바로 다리를 건널 수 있음을 뜻한다.
  • 1.00은 다리가 차로 꽉 들어차 있다는 뜻: 사실 이 경우 차량 통행에 큰 문제는 없을 테지만 차가 조금이라도 늘어난다면 통행에 문제가 생길 것이다.
  • 1.00이 넘는다면? 대기 중인 차가 있다는 뜻: 그럼 대기 중인 차량이 얼마나 되는 진 어떻게 알 수 있을까? 대기 중인 자동차가 다리 위를 이미 점유하고 있는 차들 대수만큼 있을 때의 값을 2.00으로 정하면 된다. 만약 값이 3.00이라면 다리 위의 두 배 되는 차가 대기 중인 상태를 뜻한다.

위에서 예시로 들었던 내용이 실제로 CPU load 값이 나타내는 의미이다. 대기 중인 자동차는 CPU time을 사용 중인 프로세스들을 의미하고, 대기 중인 차는 큐에 쌓인 프로세스들을 의미한다.


Unix에는 run-queue length라는 개념이 있는데, 실제로 구동 중인 프로세스 개수와 대기 중인 프로세스 개수의 총합을 의미한다.


차량이 대기 중인 것은 누가 봐도 바람직한 상황은 아니기 때문에(그리고 프로세스의 경우에도 똑같기 때문에) CPU load는 1.00 이하인 것이 바람직하다. 가끔 1.00을 넘기는 경우야 괜찮지만, 지속적으로 높은 값을 유지한다면 문제인 것이다.

 

그럼, 이상적인 로드 값이 1.00이란 말인가요?


일반적인 시스템 관리자들은 0.70 정도를 상한선으로 본다.

  • 0.70을 갓 넘었다면: 이제 슬슬 무엇이 문제인지 확인해두는 편이 좋다. 상태가 더 나빠지기 전에.
  • 1.00을 넘었다면: 당장 문제를 찾아내서 고쳐야 한다. 안 그러면 서버 때문에 자다가 불려나갈지도 모르니.
  • 5.00을 넘었다면: 정말 심각한 상황이다. 시스템이 행에 걸리거나 느려지는 중이니 이대로 두면 위험하다.


그렇다면 멀티 프로세서 환경에선 어떤가요? 지금 3.00을 찍고 있는데 잘 동작 하는걸요?


쿼드-프로세서 시스템인가? 그래도 여전히 높다.


멀티 프로세서 시스템에서의 load 값은 가용한 프로세서 코어 개수에 영향 받는다. 100% 사용 중이라면 싱글 코어는 1.00, 듀얼 코어는 2.00으로 나타날 것이다. (당연히 쿼드 코어에서는 4.00)


다리를 다시 예로 들면, 1.00은 다리 한 개의 자동차 최대 용량이다. 즉, 두 개의 다리가 있는 경우에 값이 1.00이라면, 다리 한 개만 가득 찬 상황이라는 것이다. 즉, 전체적으로 보면 50%만 점유된 상태다.


CPU에 대해서도 똑같다. 1.00이란 뜻은 싱글 코어 시스템에서 CPU가 100% 점유된 상태라는 뜻이다. 듀얼 코어 시스템에서는 당연히 2.00에 해당된다.


멀티 코어 VS 멀티 프로세서


순전히 퍼포먼스 관점에서는, 싱글 듀얼코어 프로세서나 싱글코어 프로세서 두 개나 매한가지이다. 물론 여기에는 캐시라던가 여러가지 이슈 사항들이 있지만, CPU load 관점에서는 코어 개수가 가장 중요한 이슈이다.


간단히 요약을 해 보면,

  • 코어 개수 = 최대 Load 값: 멀티 코어 시스템에서는 load가 코어 개수를 넘어가서는 안 된다.

다시 원점으로 돌아가 보자.


uptime 명령어를 입력했을 때의 결과를 한 번 살펴보자.


[root@localhost ~]$ uptime

23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36


현재 이 시스템은 듀얼코어 시스템으로, 아직 여유가 많이 남아 있음을 알 수 있다. 그럼 저 세 개의 숫자는 결국 무슨 뜻일까? 0.65는 최근 1분, 0.42는 최근 5분, 0.36은 최근 16분 간의 평균 실행/대기 중인 프로세스 수이다.


그럼 어떤 평균 값을 봐야합니까? 1분? 5분? 아니면… 15분?!


지금까지 얘기 했던 “1.00일 땐 시스템을 점검해야해요!”의 관점에서 보자면, 5분이나 15분 평균을 봐야 한다. 사실 1분 동안 잠시 1.00을 넘는 정도야 괜찮다. 15분 평균이 1.00을 넘기면 서버가 지속적인 부하 상태에 남아 있다는 뜻이므로 시스템을 점검하는 편이 좋다. (다시 한 번 강조하지만, 시스템의 코어 개수에 따라 이상적인 Load 값이 결정된다.)



출처: http://amateurteamblog.tistory.com/112 [아마추어 팀블로그]

'OS > Linux' 카테고리의 다른 글

cp -f 등 특정 옵션이 안 먹힐 때, 확인 사항  (0) 2015.03.20
yum histroy 관리법입니다.  (0) 2015.03.06
dmidecode 리눅스 하드웨어 정보 확인  (0) 2015.01.07
리눅스 파일의 속성 관련  (0) 2014.03.13
xshell 기본 설정  (0) 2013.11.12

cp -f 등 특정 옵션이 안 먹힐 때, 확인 사항

OS/Linux 2015. 3. 20. 15:56 Posted by 알 수 없는 사용자

 

백업 이나 conf 파일 들을 복사할 경우

cp –f 옵션을 사용할 때, 

image

error 가 발생할 경우가 있다.

 

alias 를  쳐보면

alias cp=’cp –i’  설정이 되어있는 경우이다.

 

cp 명령어 앞에 ‘\’를 넣어서 사용하면 alias 설정이 무시된다

 

\cp –apr

'OS > Linux' 카테고리의 다른 글

리눅스 CPU Load Average의 위험 범위는?  (0) 2017.05.12
yum histroy 관리법입니다.  (0) 2015.03.06
dmidecode 리눅스 하드웨어 정보 확인  (0) 2015.01.07
리눅스 파일의 속성 관련  (0) 2014.03.13
xshell 기본 설정  (0) 2013.11.12

yum histroy 관리법입니다.

OS/Linux 2015. 3. 6. 16:26 Posted by 알 수 없는 사용자

 

리눅스 라이브러리나 간단한 미들웨어는 yum을 통하여 관리하고 있습니다.

 

종종 라이브러리를 설치하다보면 의존성으로

다른 라이브러리도 묶여서 설치가 되는데요

 

yum의 history을 통하여 정보를 체크해 볼수 있습니다.

생각보다 깔끔하게 정리가 되네요

Action부분에 I는 Install, U는 Update 입니다.

image

 

ID 22를 조회해보면 아래같이  해당 이벤트때 변경된 내역이 출력됩니다.

image

-y install mysql-devel mysql

명령어를 통하여 설치를 진행했네요

 

해당 22번 이벤트 자체를 없애려면

rollback 명령어를 통하여 21번 이벤트로 복원이 가능합니다.

image

dmidecode 리눅스 하드웨어 정보 확인

OS/Linux 2015. 1. 7. 15:24 Posted by 알 수 없는 사용자



BIOS 나 하드웨어 스펙 확인을 할 경우가 있는데


이번 경우 같은 경우는, 

메모리 증설을 해야하는데, 현재 몇개의 슬롯이 남는지 확인하는 명령어 입니다.


dmidecode 라는 명령어를 이용하면 됩니다.


저같은 경우는


dmidecode -t 17 | egrep 'Memory | Size' 

를 통하여 현재 사용하는 메모리 슬롯과 남는 슬롯을 체크하였습니다.


참고로 -t 옵션 입니다.


-t 타입으로는 아래와 같이 있습니다. 

————————–
0 BIOS
1 System
2 Base Board 보드명칭
3 Chassis
4 Processor
5 Memory Controller
6 Memory Module
7 Cache
8 Port Connector
9 System Slots
10 On Board Devices
11 OEM Strings
12 System Configuration Options
13 BIOS Language
14 Group Associations
15 System Event Log
16 Physical Memory Array / 최대지원 메모리
17 Memory Device / 메모리 슬롯수 확인
18 32-bit Memory Error
19 Memory Array Mapped Address
20 Memory Device Mapped Address
21 Built-in Pointing Device
22 Portable Battery
23 System Reset
24 Hardware Security
25 System Power Controls
26 Voltage Probe
27 Cooling Device
28 Temperature Probe
29 Electrical Current Probe
30 Out-of-band Remote Access
31 Boot Integrity Services
32 System Boot
33 64-bit Memory Error
34 Management Device
35 Management Device Component
36 Management Device Threshold Data
37 Memory Channel
38 IPMI Device
39 Power Supply
40 Additional Information
41 Onboard Device



'OS > Linux' 카테고리의 다른 글

cp -f 등 특정 옵션이 안 먹힐 때, 확인 사항  (0) 2015.03.20
yum histroy 관리법입니다.  (0) 2015.03.06
리눅스 파일의 속성 관련  (0) 2014.03.13
xshell 기본 설정  (0) 2013.11.12
history에 시간남기기  (0) 2013.10.31

리눅스 파일의 속성 관련

OS/Linux 2014. 3. 13. 18:52 Posted by 알 수 없는 사용자

안녕하세요 서초센터 김해관 사원입니다.

금일 고객사 업무 처리중 서버에 업로드된 웹쉘 파일을 삭제 하려는 중 삭제가 되지 않아 확인 한 부분 공유 드립니다.

rm -rf 명령어로 파일삭제 시

rm: cannot unlink '파일명': Operation not Permitted

lsattr 파일명 으로 팡리의 속성설정내용을 확인 합니다

상기와 같이 i옵션과 a옵션이 설정되어 있어 파일이 삭제되지 않았습니다.

해당 옵션은 chattr 명령어를 사용 하여 제거 할수 있습니다.

chattr의 사용형식은 다음과 같습니다.

명령어위치 : /usr/bin/chattr

사용형식 : chattr [-RV] [-v 설정버전] [+-=설정모드] 대상파일들

chattr에서 사용하는 [설정모드]는 다음과 같습니다.

+ : 지정한 속성을 부여합니다. +기호가 사용되면 지정한 속성을 부여한다는 의미입니다. : 지정한 속성을 제거합니다. -기호가 사용되면 부여된 속성을 제거한다는 의미입니다. : 원래 파일이 가지고 있던 그 속성만을 유지하게 합니다.


그리고 chattr에서의 -RVv옵션에 대한 설명은 다음과 같습니다.

-R : 서브디렉토리이하까지 그 속성을 변경할 수 있습니다.

-V : 자세한 출력모드를 제공합니다.

-v  : 지정된 파일에 버전을 설정할 수 있습니다.

또한 chattr명령어에서 무엇보다 중요한 것은 각 속성을 정확하게 이해하는 것입니다.
, chattr로 설정할 수 있는 파일(디렉토리)의 속성에는 다음과 같은 것들이 있습니다.

아래 각 속성의 의미를 정확하게 이해하시고 여러분들께서 관리하고 계시는 리눅스서버의 파일보안을 위하여 chattr로 설정(+)하시거나 또는 제거(-)하실 수 있습니다
.

아래 속성의 의미를 파악하신 후에 이어지는 실제 사용예들을 보시기 바랍니다.

a 속성

해당 파일을 추가만 할 수 있습니다.

당연히 root만이 속성변경이 가능합니다. 파일보안을 위해 주로 사용하는 속성입니다.

c 속성

이 속성이 설정된 파일은 커널에 의해 디스크상에 자동적으로 압축된 상태로 저장이 되어 있습니다.

파일을 읽을 경우에는 압축을 해제한 상태로 되돌려주며 쓰기시에는 디스크에 저장하기 전에 파일을 압축합니다
.

d 속성


이 속성이 설정된 파일은 dump
로 백업이 되지않습니다.

i 속성

이 속성이 지정되어 있다면 해당파일의 변경,
삭제, 이름변경뿐 아니라 파일추가및 링크파일도 만들 수 없게 됩니다.
변경추가가 거의 없는 부팅관련 파일들에 설정하면 부팅이 되지않는 문제로 인한 시스템장애를 줄일 수 있습니다
.
또한 a 속성과 함께 필자가 주로 사용하는 속성이기도 합니다.


s 속성

이 속성이 설정된 파일은 파일삭제가 될 경우에 해당블럭이 모두 0
으로 되어 버리고 디스크에 다시 쓰기가 발생합니다.

S 속성 이 속성이 설정된 파일은 변경이 될 경우에 디스크동기화가 일어나는 효과를 그대로 누릴 수 있습니다.


u 속성

이 속성을 가진 파일이 삭제가 되었을 경우에는 그 내용이 저장이 되며 삭제되기 전의 데이터로 복구가 가능해집니다.

따라서 chattr로 파일과 디렉토리의 속성을 지정하는 주된 이유는 허가되지않은 사용자가 파일의 변경을 못하게하는 설정을 하여 파일보안을 하기위한 것입니다.

옵션을 추가 할때는 + , 제거할 때는 - 를 사용 하여 추가 및 제거 할수 있습니다.

해당 옵션을 삭제 한 후 rm 명령어를 통하여 삭제 시 정상 삭제 되었습니다.

감사합니다.


'OS > Linux' 카테고리의 다른 글

yum histroy 관리법입니다.  (0) 2015.03.06
dmidecode 리눅스 하드웨어 정보 확인  (0) 2015.01.07
xshell 기본 설정  (0) 2013.11.12
history에 시간남기기  (0) 2013.10.31
Swap 메모리 늘리기  (0) 2013.08.25

xshell 기본 설정

2013. 11. 12. 14:13

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

history에 시간남기기

2013. 10. 31. 11:59

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Swap 메모리 늘리기

2013. 8. 25. 05:59

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Clusterssh 설치

2013. 4. 22. 09:26

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

LVS HA 구성

2013. 4. 19. 15:53

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.