'지메이트 행사' 카테고리의 다른 글
2018년 10주년 기념 워크샵 (0) | 2018.06.21 |
---|---|
2017년 하반기 체육대회 (0) | 2017.10.27 |
2017년 상반기 워크샵 (0) | 2017.06.26 |
2016년 종무식 (0) | 2017.02.23 |
2016년 하반기 체육대회 (0) | 2016.10.12 |
2018년 10주년 기념 워크샵 (0) | 2018.06.21 |
---|---|
2017년 하반기 체육대회 (0) | 2017.10.27 |
2017년 상반기 워크샵 (0) | 2017.06.26 |
2016년 종무식 (0) | 2017.02.23 |
2016년 하반기 체육대회 (0) | 2016.10.12 |
01
2
2018년 하반기 체육대회 (0) | 2018.10.29 |
---|---|
2017년 하반기 체육대회 (0) | 2017.10.27 |
2017년 상반기 워크샵 (0) | 2017.06.26 |
2016년 종무식 (0) | 2017.02.23 |
2016년 하반기 체육대회 (0) | 2016.10.12 |
2018년 하반기 체육대회 (0) | 2018.10.29 |
---|---|
2018년 10주년 기념 워크샵 (0) | 2018.06.21 |
2017년 상반기 워크샵 (0) | 2017.06.26 |
2016년 종무식 (0) | 2017.02.23 |
2016년 하반기 체육대회 (0) | 2016.10.12 |
Apache Log에서 특정 문자열만 별도로 분리할 경우가 생겨서
작업 진행해보았습니다.
httpd.conf 내에
==============================================================
SetEnvIfNoCase Request_URI "/download/temp/pdfexport" customlog2
SetEnvIfNoCase Request_URI "exportword" customlog2
CustomLog "|/app/apache/bin/rotatelogs -l /app/log/apache/export_%Y%m%d.log 86400" combined env=customlog2
==========================================================
설정 추가
access로그에
"/download/temp/pdfexport"
"exportword"
라는 문자열이 있는 Log는
export_날짜.log 형태로 분리시키는 설정
출처: http://eun2jong.com/ [< eun2jong.com > 은이종]
mod_define (0) | 2016.05.17 |
---|---|
Apache rewrite 정리 (0) | 2016.01.28 |
SSL 인증서 비밀번호 제거 확인 (0) | 2015.12.30 |
SSL 인증서 알고리즘 정리 (0) | 2015.12.16 |
Apache pagespeed 설치 (0) | 2015.03.18 |
2018년 10주년 기념 워크샵 (0) | 2018.06.21 |
---|---|
2017년 하반기 체육대회 (0) | 2017.10.27 |
2016년 종무식 (0) | 2017.02.23 |
2016년 하반기 체육대회 (0) | 2016.10.12 |
2016년 상반기 워크샵 (0) | 2016.06.16 |
Microsoft 보안 업데이트가 적용되지 않은 취약한 Windows 시스템을 겨냥 한 ‘WannaCry(워너크라이) 랜섬웨어’의 공격이 전세계적으로 진행되고 있습니다.
랜섬웨어란 컴퓨터 사용자의 파일을 인질로 금전을 요구하는 악성 프로그램으로 몸값을 뜻하는 랜섬(Ransom)과 소프웨어(Software)의 합성어입니다.
WannaCry 랜섬웨어 감염 시 문서 파일, DB파일등을 암호화하며, 암호를 푸는 대가로 비트 코인을 요구합니다.
WannaCry 랜섬웨어 는 Microsoft 보안 업데이트를 적용하지 않은 환경의 Windows 취약점을 악용한 것으로, 2017년 3월 발표된 Microsoft 보안 업데이트 [MS17-010 Microsoft Windows SMB 서버용 보안 업데이트(4013389)]에서 이미 이 취약점이 해결되었습니다. MS17-010 보안 업데이트 적용하여 공격을 예방할 수 있으며, 또한 해당 업데이트가 이미 적용된 Windows 시스템은 이번 공격에서 안전합니다.
아래의 대응 방법을 적용하여 이번 랜섬웨어 감염으로 인한 피해가 없으시기를 바랍니다.
[WannaCry 랜섬웨어 대응 방법]
l 조치 방법
① 사용하고 있는 백신 소프트웨어를 최신으로 업데이트하고 시스템을 검사합니다.
만일 설치된 백신 소프트웨어가 없다면 Microsoft 백신 소프트웨어를 이용하십시오.
Windows Defender 와 Microsoft Anti-Malware 제품의 최신 엔진 버전 1.243.290.0 에서 Ransom:Win32/WannaCrypt 로 해당 맬웨어가 차단됩니다.
- Windows 8.1 및 Windows 10 : Windows Defender 이용
- Windows 7, Windows Vista: Microsoft Security Essentials 이용
- Microsoft 무료 PC보안 검사 : Microsoft Safety Scanner 이용
② Windows Update 또는 WSUS등을 이용하여 시스템을 최신으로 보안 업데이트 합니다.
WU을 사용할 수 없는 경우, Microsoft 보안 업데이트 MS17-010 를 수동 설치합니다. OS별 설치 경로는 아래와 같습니다.
Microsoft 보안 공지 MS17-010 – 긴급 Microsoft Windows SMB 서버용 보안 업데이트(4013389)
https://technet.microsoft.com/ko-kr/library/security/ms17-010.aspx
추가 정보
- Microsoft Security Response Center Blog, Customer Guidance for WannaCrypt attacks : https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/
- Microsoft Malware Protection Center Blog, WannaCrypt ransomware worm targets out-of-date systems: https://blogs.technet.microsoft.com/mmpc/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/
- Microsoft 보안 공지 MS17-010 – 긴급 Microsoft Windows SMB 서버용 보안 업데이트(4013389) : https://technet.microsoft.com/ko-kr/library/security/ms17-010.aspx
- CVE-2017-0145 | Windows SMB 원격 코드 실행 취약성 : https://portal.msrc.microsoft.com/ko-kr/security-guidance/advisory/CVE-2017-0145
MySQL 신규 취약점 업데이트 발표 (0) | 2016.10.11 |
---|---|
OpenSSL 신규 취약점 보안 업데이트 발표 (0) | 2016.10.11 |
OpenSSL의 신규 취약점에 대한 긴급 보안업데이트 발표 (0) | 2016.03.10 |
SSL 보안인증서 COMODO SHA1 적용 사이트 접속 불가 이슈 (0) | 2015.12.18 |
리눅스 Ghost 취약점 보안 업데이트 권고 (CVE-2015-0245) (0) | 2015.01.29 |
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차선 도로와 같다. 어떨 땐 다리를 건너려는 차들이 많아 다리 위가 매우 혼잡할 것이다. 그럼 다리 위가 얼마나 혼잡한 지를 어떻게 수치로 나타낼 수 있을까? 제일 간단한 방법은 특정 시간 동안 얼마나 많은 차가 건너려고 대기 중인지 파악하는 것이다.
만약에 대기 중인 차가 없다면 바로 다리를 건널 수 있을 것이고, 대기 중인 차가 있다면, 당연히 기다려야 한다. 종합해보면 다음과 같은 정책을 쓸 수 있다.
위에서 예시로 들었던 내용이 실제로 CPU load 값이 나타내는 의미이다. 대기 중인 자동차는 CPU time을 사용 중인 프로세스들을 의미하고, 대기 중인 차는 큐에 쌓인 프로세스들을 의미한다.
Unix에는 run-queue length라는 개념이 있는데, 실제로 구동 중인 프로세스 개수와 대기 중인 프로세스 개수의 총합을 의미한다.
차량이 대기 중인 것은 누가 봐도 바람직한 상황은 아니기 때문에(그리고 프로세스의 경우에도 똑같기 때문에) CPU load는 1.00 이하인 것이 바람직하다. 가끔 1.00을 넘기는 경우야 괜찮지만, 지속적으로 높은 값을 유지한다면 문제인 것이다.
그럼, 이상적인 로드 값이 1.00이란 말인가요?
일반적인 시스템 관리자들은 0.70 정도를 상한선으로 본다.
그렇다면 멀티 프로세서 환경에선 어떤가요? 지금 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 관점에서는 코어 개수가 가장 중요한 이슈이다.
간단히 요약을 해 보면,
다시 원점으로 돌아가 보자.
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 [아마추어 팀블로그]
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 |
2017년 하반기 체육대회 (0) | 2017.10.27 |
---|---|
2017년 상반기 워크샵 (0) | 2017.06.26 |
2016년 하반기 체육대회 (0) | 2016.10.12 |
2016년 상반기 워크샵 (0) | 2016.06.16 |
2015년 종무식 (0) | 2015.12.24 |
Tomcat 6, 7에서 8로 마이그레이션 시 유의해야할 사항
1. MaxPermSize 명칭 변경
- MaxPermSize => MaxMetaspaceSize
- PermSize => MetaspaceSize
2. conf/server.xml
- maxActive => maxTotal
- maxWait = maxWaitMillis
- remobeAbandoned => removeAbandonedOnBorrow or removeAbandonedOnMaintenance
- validationInterval => validationQueryTimeout 으로 변경
- mysql 사용시 initiaiSize 관련 오류가 발생하는 것 => jennifer에서 enable_jdbc_wrapper = true enable_reserved_sql_pointcut=false로 설정 변경 필요
3. conf/web.xml
- jsp 스펙 변화에 따른 내용 수정을 해야함
-- auth-constraint절 제거 또는 security-role절 추가
<security-role>
<role-name>manager</role-name>
</security-role>
auth-constraint의 role-name에 manager 추가
4. Catalina 하위에 있는 manager.xml 제거 그리고 webapps/manager 제거
5. conf/web.xml 혹은 ~~~war/WEB-INF/web.xml
- jsp 스펙 변화에 따른 내용 수정을 해야함
- resource-ref에서 description 제거
6. jdbc 드라이버는 반드시 $TOMCAT/lib에 위치해야함
etc. tomcat의 HTTP2 채용으로 인한 native apr 관련해서 업데이트 필요
Tomcat MaxPermSize (0) | 2016.09.06 |
---|---|
Tomcat connector (mod_jk) 관련 주의사항 (0) | 2015.11.04 |
JK FAQ (0) | 2013.11.22 |
2017년 상반기 워크샵 (0) | 2017.06.26 |
---|---|
2016년 종무식 (0) | 2017.02.23 |
2016년 상반기 워크샵 (0) | 2016.06.16 |
2015년 종무식 (0) | 2015.12.24 |
2015년 가을 체육대회 (0) | 2015.10.28 |