All posts by Enteroa

AWS – EBS 타입 gp3

aws 의 EC2 인스턴스에 연결하여 사용하는 EBS(disk) 의 경우 기존에 gp2 만 존재 했었다.

이번 reinvent 2020 에서 발표된 gp3가 기존 gp2가 어떤 부분이 다른지 확인을 해본다.

가격테이블(리전: Seoul/ap-northeast-2)

	gp2 GB / month	gp3 GB / month	gp3 IOPS( 1 )	gp3 Throughput( 1 MiB )
가격	US$ 0.114	US$ 0.0912	US$ 0.0057	US$ 0.0456
크기	1 ~ 16384 GB	1 ~ 16384 GB
IOPS	100 ~ 16000 disk 크기에 따른 자동조정	3000 ~ 16000 기본값 3000 이상 옵션 과금 제한 DISK크기 1MB : 500 IOPS
Throughput	125 ~ 250 MiB disk 크기에 따른 자동조정	125 ~ 1000 MiB 기본값 125 이상 옵션 과금 제한 4 IOPS : Throughput 1 MiB

gp2 에서는 IOPS 가 34GB ~ 5334GB 에서 디스크 자동 조정이 되었고, Throughput 의 경우 168 GB ~ 334 GB 에서 자동 조정이 되었다.

모든 경우값을 다 대입 할순 없겠지만 엑셀로 정리했을때 아래와 같다.

상위 표중 gp3 max speed 는 최대의 IOPS 및 Throughput 으로 하게 되며 디스크 크기에 따라아래와 같이 속도가 제한 되었다.

8GB = 4000 IOPS, Throughput 750 MiB

30GB = 15000 IOPS, , Throughput 1000 MiB(max)

기본적인 가격은 낮아졌기 때문에 gp2 보다는 gp3 를 선택해서 사용 하는게 이익이다.

다만 단순히 TYPE 만 변경 하게 될 경우 속도 상에서 기존 gp2에 비해 느릴 수 있겠다. 때문에 적절히 IOPS 와 Throughput 을 적용하는것이 좋겠다.

그래프로 그려봤을땐 아래와 같다.

좀더 현실적으로 많이 사용할 500GB 까지의 그래프는 아래와 같다.

gp2 에서 gp3 으로의 이행을 할 경우 성능 조정 없이 사용할 경우 사용료가 20% 절약이 된다.

gp2 -> gp3 로의 볼륨 수정은 서버가 running 상태에서도 변경이 가능하다. (용량에 따라 optimizing 시간이 좀 걸린다.)

Linux 에서의 IO 테스트 방법 1

~]# dd if=/dev/zero of=test bs=16k count=10000 oflag=direct && rm -f test

~]# dd if=/dev/zero of=test bs=1M count=1024 oflag=direct && rm -f test

Linux 에서의 IO 테스트 방법 2

1 2	~]# hdparm --direct -t -T /dev/nvme0n1p1

		dd ( 16k / 10000 times)	dd ( 1M / 1000 times )	hdparm
12GB	gp2 100 IOPS 125MiB (추정)	29.5 MB/s	154 MB/s	cached: 191.81 MB/sec disk: 170.53 MB/sec
12GB	gp3 3000 IOPS 125 MiB	23.8 MB/s	149 MB/s	cached: 187.18 MB/sec disk: 166.64 MB/sec
120GB	gp2 - 360 IOPS 125MiB (추정)	28.8 MB/s	153 MB/s	cached: 191.71 MB/sec disk: 170.58 MB/sec
120GB	gp3 3000 IOPS 125 MiB	16.0 MB/s	149 MB/s	cached: 187.42 MB/sec disk: 166.60 MB/sec
500GB	gp2 IOPS 1500 250MiB (추정)	34.3 MB/s	347 MB/s	cached: 375.03 MB/sec disk: 333.46 MB/sec
500GB	gp3 3000 IOPS 250 MiB	23.0 MB/s	347 MB/s	cached: 375.04 MB/sec disk: 333.47 MB/sec
1024GB	gp2 IOPS 3072 250MiB (추정)	30.9 MB/s	345 MB/s	cached: 374.96 MB/sec disk: 333.50 MB/sec
1024GB	gp3 3000 IOPS 125 MiB	20.6 MB/s	149 MB/s	cached: 187.51 MB/sec disk: 166.63 MB/sec
2048GB	gp2 IOPS 6144 250MiB (추정)	28.0 MB/s	347 MB/s	cached: 375.04 MB/sec disk: 333.22 MB/sec
2048GB	gp3 3000 IOPS 125 MiB	23.7 MB/s	149 MB/s	cached: 187.50 MB/sec disk: 166.63 MB/sec

성능 테스트 결과 최대 속도의 경우 gp2 와 gp3가 동등하다.
gp3의 장점은 사용료가 저렴한 부분과 크레딧이 없어 일정한 속도가 유지 되는면이 있고,
아울러서 gp2 의 경우 높은 성능을 원하는 경우 디스크 크기를 증가 시켜야 하는데
gp3의 경우 성능만 높일 수 있다는 점이 장점이라고 할 수 있겠다.

gp3의 단점은 작은 용량의 파일 처리에서는 속도가 gp2에 비해 떨어진다.

Block Size	16kB	32kB	64kB
Bps	16.0 MB/s	31.6 MB/s	62.4 MB/s

Block Size	128kB	256kB	512kB
Bps	106 MB/s	135 MB/s	150 MB/s

테스트 블럭 사이즈에 비례 하게 속도가 늘어난다 @_@a

Machine Learning 공부 – PlaidML

말로만 듣지 말고 해보자 라는 개념으로 시작했다.

Anaconda3 64비트를 설치 하고 파이선의 venv를 생성 한뒤에 tensorflow 설치 및 keras 설치를 진행 한다.

C:\somewhere> set CONDA_FORCE_32BIT=

C:\somewhere> conda create -n py38_64_ml_test

C:\somewhere> activate py38_64_ml_test

C:\somewhere> pip install numpy pandas matplotlib sklearn tensorflow==2.3.0 keras==2.4.3

이후 메뉴얼의 트레이닝을 했을때 CPU 연산을 하는것으로 확인이 되었고

연습용 PC 으로 AMD 르누아르 계열을 쓰고 있기 때문에 GPU 연산을 위해 PlaidML 을 설치 진행 하였다.

C:\somewhere> activate py38_64_ml_test

C:\somewhere> pip install plaidml

C:\somewhere> plaidml-setup

setup시 대화형인데 동의, 그래픽카드선택, 저장 에 순서 의다.

사용방법 – keras를 이용하는 코드에서 아래와 같이 선언만 하면 된다.

1 2	import plaidml.keras plaidml.keras.install_backend()

테스트1 – plaidbench

C:\somewhere> activate py38_64_ml_test

C:\somewhere> pip install plaidml-keras plaidbench

C:\somewhere> plaidbench keras mobilenet

테스트2 – python 코드 VGG19

#!/usr/bin/env python

import numpy as np

import time

import plaidml.keras

plaidml.keras.install_backend()

import keras

import keras.applications as kapp

from keras.datasets import cifar10

(x_train, y_train_cats), (x_test, y_test_cats) = cifar10.load_data()

batch_size = 8

x_train = x_train[:batch_size]

x_train = np.repeat(np.repeat(x_train, 7, axis=1), 7, axis=2)

model = kapp.VGG19()

model.compile(optimizer='sgd', loss='categorical_crossentropy',

metrics=['accuracy'])

print("Running initial batch (compiling tile program)")

y = model.predict(x=x_train, batch_size=batch_size)

# Now start the clock and run 10 batches

print("Timing inference...")

start = time.time()

for i in range(10):

y = model.predict(x=x_train, batch_size=batch_size)

print("Ran in {} seconds".format(time.time() - start))

잘 돌기는 도는데 이게 지금 GPU 연산을 하는가? 라는 의문이 있었다.

위와 같이 작업 관리자의 GPU 그래프가 너무나도 잠잠했기 때문에..

트레이닝을 시켰을때 GPU의 메모리 사용량이 늘은 것을 확인 했으나 GPU 코어 측정 부분이 가만히 있고 덩달아 시스템의 cpu / mem 사용량이 늘어 났다.

자세히 디버깅을 하면서 실행 해보니 AI 트레이닝 이전에 CPU/MEM 사용량이 먼저 증가 하였다 ‘ㅅ’a

구동 시나리오상 python도 같이 돌기 때문에 python 이 학습 및 테스트 데이터를 dataframe 에 넣을때 cpu 및 memory 사용량이 늘어나는것 같다.

윈도우 작업 관리자의 GPU 부분은 3D / Copy / Video Encoding, Decoding 등등만 보여주기 때문에 트레이닝시 GPU 로드 그래프 확인이 안되는것으로 추정 된다.

그래서 찾은 방법은 GPU-Z 를 설치해서 모니터링 하는 것이다.

잘된다 🙂

다른 방법으로는 트레이닝 시간을 측정해 볼수 있겠다.

CPU연산을 했을때에는 5 columns, 110,281 rows 를 LSTM 연산을 했을때 약 35분 11초(2111초)가 소요 되는 트레이닝이 GPU 연산을 했을때 5분 46초(346초)로 단축이 되었다.

PS. PlaidML 은 intel 이 만들었고 keras backend 를 연결하여 intel, AMD gpu를 쓸수 있게 해주는 패키지 이다 ‘ㅅ’a

Nvidia 가 만든 CUDA를 이용하는 구글의 tensorflow 를 쉽게 쓰게 도와주는 keras…

이와 별개로 AMD가 구축하는 ROCm 이 있다 ‘ㅅ’a (이거는 나중에 스스로 공부할때 사용할 키워드를 주절주절 써놓은것…)

S3 버킷 CORS 설정 (json)

S3 의 CORS 설정이 기존 XML 방식에서 Json 방식으로 변경이 되었다 ‘ㅅ’a

웹콘솔에서 s3 버킷을 선택 하고 관리 탭의 하단에 있다.

사실 문법만 틀리겠지만 미리 정리를 해본다.

다음은 가장 일반적인 형태의 자신의 도메인 주소를 추가 하는 방법이다.

[

{

"AllowedOrigins": [ "https://enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "https://*.enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "http://enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "http://*.enteroa.com" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

}

]

IDE를 가지고 개발하는 경우.. 개발자 PC 에서 웹서버가 자주 실행하고 테스트 해야 된다면 아래와 같이 localhost:* 을 추가 한다.

[

{

"AllowedOrigins": [ "http://localhost:*" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

{

"AllowedOrigins": [ "http://127.0.0.1:*" ],

"AllowedMethods": [ "GET", "PUT", "POST", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

}

]

모든 곳에 허용(메일 삽입 이미지 등등) 하는 것은 Origin 설정을 * 으로 하면 된다 ‘ㅅ’a

[

{

"AllowedOrigins": [ "*" ],

"AllowedMethods": [ "GET", "HEAD" ],

"AllowedHeaders": [ "*" ],

"ExposeHeaders": [ "x-amz-server-side-encryption", "x-amz-request-id", "x-amz-id-2" ],

"MaxAgeSeconds": 3000

}

]

AllowedMethods 는 GET, POST, HEAD, PUT, DELETE 를 지정 할수 있다.

PS. 터미널에서 curl 으로 CORS 검사는 아래와 같이 할 수 있다.

~]# curl -sI \

-H 'Origin: http://test.com' \

-H 'Access-Control-Request-Headers: Origin, Accept, Content-Type' \

-H 'Access-Control-Request-Method: GET' \

https://enteroa-bucket.s3-us-west-2.amazonaws.com/img/123.jpg

2.4Ghz 대역의 블루투스 및 wifi 와 USB3 간섭

USB 는 Universal Serial Bus 이고 일상적으로 쓰는 규격이다.

버전에 따라 최대 대역폭이 달라지는 것은 파동 간격을 줄여 같은 시간에 좀더 많은 데이터 전송을 가능하게 한다.

위는 느린 USB 2.0 의 신호 형식(60MB/sec) 아래는 USB 3.0 의 신호 형식(625MB/sec)으로 이해 하면 되겠다.

모든 전자기기는 작동시 전자파를 발생시키는데 USB 3.0 에서 생성하는 전자파가 현재 주로 많이 쓰는

2.4Ghz (블루투스, WIFI) 에 간섭이 이루어 진다. 주로 신호 간섭 때문에 렉 혹은 튀는 증상이다.

이름만 바꾼 (USB 3.1 gen1 / USB 3.2 gen1x1) 도 포함 된다.

문서 내용을 종합 하면

이 그림은 일반적인 사용 환경과 비슷하다. (CASE 1)

보통 usb 2 or 3 가 혼재 되어 있고 그림과 같이 쓰게 되는데

마우스가 2ft (약 70Cm) 이상 멀어지면 렉이 발생한다고 한다.

CASE 2 의 경우에는 usb 2.0 허브를 이용하여 USB3 포트에서 멀리 떨어트려 사용하는 것을 테스트 한

내용인듯 하여 2ft ~ 5ft (70Cm~180Cm) 까지 정상 사용이 가능했다고 한다 ‘ㅅ’a

CASE 3의 경우에는 usb 2 및 3 포트가 위아래로 바로 붙어 있는 형태

(가끔 메인보드에서 본적 있다.) 에서는 2ft ~ 5ft (70Cm~180Cm) 모두 사용 불가.

결론.

wifi 및 블루투스 동글 등은 usb 2.0 허브를 이용해 usb3 에서 2ft 가까이 떨어트려서 사용한다.
인터넷 공유기에 포함된 USB 3.0 은 사용하지 말아야 한다.
USB의 상위 버전은 하위 버전을 연결 할경우 하위 프리퀀시로도 동작이 가능하기 때문에 3.0 포트에 USB 2.0 장치 혹은 허브를 연결해도 된다.
USB 3.0 과 USB 3.1 gen1 과 USB 3.2 gen1 은 단순 리브랜딩 이기 때문에 같은 문제가 있을것으로 판단 된다. (기술적으로 usb 2.0과 usb 3.x gen2 는 좋다 ‘ㅅ’a
USB 3.0 허브를 사용하는 방법은 연결 부위 두곳 모두에서 발생하기 때문에 무선 충돌 해결에 1도 도움이 되지 않는다.
어쩔수 없는 경우에는 금속 쉴딩으로 어느정도는 해결이 가능하다. (물론 절연처리 된 금속 쉴딩)
가격적인 고려를 하면 다이소표 usb 2.0 연장 케이블(1M) 약 1,000원 정도 하는걸 사서 동글을 다른 usb 장치 및 연결 부와 이격 시키는게 가장 간단 하다.
https://search.shopping.naver.com/search/all?query=usb 2.0 연장 케이블

PS. 쉴딩 처리 영역에 따른 전파 생성 그래프 ‘ㅅ’a (개인이 EMI 테이프 를 구하는것도 쉽지 않을듯.)

외장 하드 기판에 쉴딩
USB 커넥터 부위에만 쉴딩
USB 커넥터 및 커넥터 주위 기판까지 쉴딩
외장 하드 전체 쉴딩 (알루미늄 or 구리 EMI 필터)

CentOS 7 에서 systemd 의 쓸모 없는 로그를 필터링

시스템 로그 분석을 매주 진행하는데 systemd 에서 아래와 같은 메세지가 많이 표현됨.

Sep 23 00:00:00 HOSTNAME systemd: Started Session XXXXXXXX of user root.

Sep 23 00:00:00 HOSTNAME systemd: Starting Session XXXXXXXX of user root.

Sep 23 00:00:00 HOSTNAME systemd: Removed session XXXXXXXX.

Sep 23 00:00:00 HOSTNAME systemd: Starting User Slice of root.

Sep 23 00:00:00 HOSTNAME systemd: Stopping User Slice of root.

Sep 23 00:00:00 HOSTNAME systemd: Created slice user-X.slice.

Sep 23 00:00:00 HOSTNAME systemd: Removed slice user-X.slice.

Sep 23 00:00:00 HOSTNAME systemd: Starting user-X.slice.

Sep 23 00:00:00 HOSTNAME systemd: Stopping user-X.slice.

로그 분석할때 쓸모가 없기 때문에 rsyslog 에서 예외 적용 한다.

~]# echo 'if $programname == "systemd" and ($msg contains "Removed session" or $msg contains "Starting User Slice of" or $msg contains "Stopping User Slice of" or $msg contains "Created slice" or $msg contains "Removed slice" or $msg contains "Starting user-" or $msg contains "Stopping user-" or $msg contains "Started Session" or $msg contains "Starting Session") then stop' > /etc/rsyslog.d/ignore-systemd-session-slice.conf

~]# systemctl restart rsyslog

출처 : https://access.redhat.com/solutions/1564823