유니코드 문서의 Byte Order Mark

보통 일반적으로 접하게 되는 문서는 ASCII 혹은 UTF8 문서 이다.

다만 문서중 UTF8 의 경우 일반 UTF8, UTF8 (BOM) 문서가 있다.

UTF8 (BOM)의 경우 윈도우 메모장에서 UTF8문서를 생성할 경우 파일의 첫부분에 삽입되게 되며 “EF BB BF” 값을 가진다.

또란 실제 삽입되어 있지만 메모장으로 파일을 불러들였을때에는 보이지 않도록 처리가 되어 있다.

즉 있는지 없는지 확인이 안되고 오류를 발생시키기 때문에 문제가 된다.

아래 처럼 utf8 에서는 ea b0 80 = “가” 을 나타낸다.

~]# echo $LANG

en_US.UTF-8

~]# echo -n '가' | xxd

0000000: eab0 80 ...

일반 ASCII 파일 혹은 일반(리눅스에서 생성한) UTF8 문서를 확인해보면 아래와 같다. # = 23 | 가 = ea b0 80 | \n(엔터) = 0a

~]# file test.txt

test.txt: UTF-8 Unicode text

~]# xxd test.txt

0000000: 2323 2323 2323 2323 2323 2323 2323 2323 ################

0000010: 2323 2323 2323 2323 2323 2323 2323 2323 ################

0000020: eab0 800a ....

~]# file test2.txt

test2.txt: ASCII text

~]# xxd test2.txt

0000000: 2323 2323 2323 2323 2323 2323 2323 2323 ################

0000010: 2323 2323 2323 2323 2323 2323 2323 2323 ################

0000020: 0a .

윈도우 메모장으로 생성\하여 BOM 이 삽입된 파일은 다음과 같다. utf8(bom) = ef bb bf | \r\n(윈도우엔터) = 0d 0a

~]# file test3.txt

test3.txt: UTF-8 Unicode (with BOM) text, with CRLF line terminators

~]# xxd test3.txt

0000000: efbb bf23 2323 2323 2323 2323 2323 2323 ...#############

0000010: 2323 2323 2323 2323 2323 2323 2323 2323 ################

0000020: 2323 230d 0a ###..

위와 같은 이유로 윈도우에 mysql 을 설치 하고 메모장으로 my.ini 파일을 수정한뒤에 저장 하면 UTF-8(BOM) 으로 저장 되어 mysql 서비스 시작이 되지 않는다.

메모장으로 하더라도 “다른 이름으로 저장” 시 인코딩을 ANSI 으로 설정하고 저장 기존 파일명과 같게 저장 하는 방법이 있다. (근데 사람은 같은 실수를 반복하기 때문에…)

윈도우 내에서의 문서 작업은 메모장이 아닌 BOM 없이 생성 가능한 에디터를 사용하는 습관을 들여야 할것 같다 ‘ㅅ’a

무료 툴 : AcroEDIT

PS. UTF16 의 경우 UTF16BE , UTF16LE 두가지 형식이 존재하며 두가지 모두 Byte Order Mark 를 가지고 있다. 아래표 참조 ‘ㅅ’a

	Byte Order Mark	문자 길이	HEX 코드 ( # )	HEX 코드 ( 가 )	HEX 코드 ( 핣 )
UTF16BE	FE FF	4 Byte	23 00	AC 00	D8 A9
UTF16LE	FF FE	4 Byte	00 23	AC 00	D8 A9
UTF8(BOM)	EF BB BF	1 ~ 3 Byte	23	EA B0 80	ED 95 A3
UTF8	-	1 ~ 3 Byte	23	EA B0 80	ED 95 A3
ASCII	-	1 Byte	23	표현 불가
UTF32BE	FE FF 00 00	8 Byte	23 00 00 00	AC 00 00 00	D8 A9 00 00
UTF32LE	00 00 FF FE	8 Byte	00 00 00 23	00 00 AC 00	00 00 D8 A9

Let’s encrypt 사용 방법 변경

Skipping bootstrap because certbot-auto is deprecated on this system.

Your system is not supported by certbot-auto anymore.

Certbot cannot be installed.

Please visit https://certbot.eff.org/ to check for other alternatives.

신규 서버를 세팅 하고 SSL 추가 했을때 당황스럽게도 위와 같은 메세지를 뿌리며 certbot-auto 가 작동하지 않았다.

certbot-auto 의 경우 실행 시킬때마다 자동 업데이트를 하는데 버전이 1.11 버전으로 되어 있을경우 발생하는 메세지로 확인이 된다.

링크를 따라 갈 경우 snap을 이용해서 설치해서 사용하라고 안내 되어 있다.

snap 은 yum 혹은 apt-get 과 같은 패키지 관리 툴 이다.

CentOS 7.7~8.X 의 경우 epel-release 가 설치 되어 있다면 yum 으로 snap을 설치할 수 있다. (6번 라인은 양반김 처럼 두번 실행해야 할 수 있다.)

~]# yum install snapd

~]# ln -s /var/lib/snapd/snap /snap

~]# systemctl enable --now snapd.socket

~]# snap install core

~]# snap refresh core

이후에 snap 을 이용하여 certbot 을 설치한다.

주의: 기존에 yum 이나 apt-get 혹은 dnf 으로 설치된 certbot은 삭제 하고 진행 해야 한다. (일부 버전에서 심볼링 링크가 안걸리는듯… 하여 8번 라인의 명령어를 추가 실행해야 할 수 있다.)

~]# snap install --classic certbot

~]# ln -s /snap/bin/certbot /usr/bin/certbot

~]# certbot --version

certbot 1.14.0

### 버전이 확인 되지 않는 경우 아래와 같이 심볼릭 링크를 추가 해야 한다.

~]# ln -s /usr/bin/snap /var/lib/snapd/snap/bin/certbot

/usr/bin 안으로 링크를 생성하기 때문에 ssl 발급/삭제을 위해서는 아래 명령어를 사용하면 되겠다.

~]# certbot certonly --server https://acme-v02.api.letsencrypt.org/directory \

--rsa-key-size 4096 --agree-tos --email 이메일@주소 --webroot -w /var/www/html \

-d www.도메인 -d 도메인

~]# certbot revoke --cert-path /etc/letsencrypt/live/도메인/cert.pem

장점이 하나 있는데 snapd 에서 sequence 기능으로 설치된 패키지를 자동으로 최신 업데이트를 하는데

발급된 인증서의 renew 역시 자동으로 처리가 된다. (/var/lib/snapd/sequence/certbot.json)

PS1 . 기존에 git 에서 clone 을 해서 사용한 경우 삭제까지는 필요 없는듯 하고, renew의 경우 메세지는 나오지만 갱신 하는데에는 문제가 없다.

PS2. snap 설치가 되지 않는 리눅스의 경우 certbot-auto 구버전 (1.9.0.dev0) 의 실행파일만 덧씌운뒤 renew 실행하면 당장 급한불을 끌 수 있음.

~]# wget https://raw.githubusercontent.com/certbot/certbot/7f0fa18c570942238a7de73ed99945c3710408b4/letsencrypt-auto-source/letsencrypt-auto -O /opt/certbot-auto

~]# chmod 755 /opt/certbot-auto

~]# mv /opt/certbot-auto /기존설치경로/certbot-auto

PS3. 테스트 해보지 않았으나 acme api를 이용하는 bash, dash, sh 비공식(호환) 스크립트.. https://github.com/acmesh-official/acme.sh

python – apache pyarrow 를 이용한 parquet 생성 및 테스트

apache 재단에서 진행 되는 프로젝트 이다. python, java, R 등등 많은 언어를 지원 한다.

CSV (Comma-Separated Values)의 가로열 방식의 데이터 기록이 아닌 세로열 기록 방식으로 기존 가로열 방식에서 불가능한 영역을 처리가 가능하도록 한다.

보이는가 선조의 지혜가 -3-)b

이미지 출처: 훈민정음 나무위키

차이점을 그림으로 표현하자면 아래와 같다.

문서를 모두 읽는다 에서는 큰 차이가 발생하지 않지만 구조적으로 모든 행이 색인(index) 처리가 된 것처럼 파일을 읽을 수 있다.

sql 문으로 가정으로 “(SELECT * FROM 테이블 WHERE 재질 = ‘철’)” 을 찾게 될 경우 index 가 둘다 없다는 가정하에서

CSV 는 9개의 칸을 읽어야 하지만 (재질->무게->산화->나무->가벼워->탄다->철->무거워->안탄다->return)

parquet 의 경우 5개의 칸만 읽으면 된다. (재질->나무->철->무거워->안탄다->return)

PS. 물론 색인(index) 는 이런 구조가 아닌 hash 처리에 따른 협차법 으로 찾아서 빨리 찾을 수 있어 차이가 있다.

압축을 하더라도 컬럼별 압축이 되기 때문에 필요한 내용만 읽어서 압축해제 하여 데이터를 리턴 한다.

적당한 TSV (Tab-Separated Values)데이터를 준비 한다.

python 을 이용하여 TSV 파일을 읽고 python 의 pyarrow를 이용하여 parquet 파일을 생성 하고 읽는 테스트를 한다. (pyarrow, pandas 는 pip install pyarrow pandas 으로 설치할 수 있다.)

#!/usr/bin/env python

# -*- coding: utf-8 -*-

import os

import time

import pandas as pd

import pyarrow as pa

import pyarrow.parquet as pq

from pyarrow import csv

def tsv2parquet(filename, skiphead, column_length, toformat):

if toformat in ('none', 'snappy', 'gzip', 'lzo', 'brotil', 'lz4', 'zstd'):

if skiphead == 0:

skiphead = None

table_columns = [str(i) for i in range(0, column_length)]

r_opt = csv.ReadOptions(skip_rows=skiphead, column_names=table_columns, use_threads=False)

p_opt = csv.ParseOptions(delimiter='\t')

pyarrow_table = csv.read_csv(fname, read_options=r_opt, parse_options=p_opt)

outname = os.path.splitext(fname)[0]+'.'+toformat+'.parquet'

pq.write_table(pyarrow_table, outname, compression=toformat)

else:

print('didn\'t support format: '+ toformat)

exit(1)

return outname

print('pyarrow version:', pa.__version__) # print pyarrow Version

fname = "sample/shjang_Genome_20191011.txt" # Target file (TSV)

sh = 4 # file header line.

cc = 10 # column count

out_format = 'gzip' # pyarrow 0.16 support: 'none', 'snappy', 'gzip', 'lz4', 'zstd'

print('File size: ' + str(os.path.getsize(fname)))

ts = time.time()

outfile = tsv2parquet(fname, sh, cc, out_format) # make parquet file.

print('make parquet(' + out_format + ') file: ' + str(round(time.time() - ts, 2)) + ' sec')

ts = time.time()

dataframe = pd.read_parquet(outfile, engine='pyarrow')

print('parquet -> pandas -> dataframe: ' + str(round(time.time() - ts, 2)) + ' sec')

ts = time.time()

dataframe = pq.read_table(outfile).to_pandas()

print('parquet -> pyarrow -> dataframe: ' + str(round(time.time() - ts, 2)) + ' sec')

exit(0)

TSV -> parquet 압축률(높을수록 좋음) 및 처리 시간(낮을수록 좋음)

	def	ext	MB	compress ratio	processing time python 2.7	processing time python 3.6
txt		.txt	58.8 MB
gzip		.txt.gz	16.3 MB	72%	3.24 sec
pyarrow	write_table, compression='none'	.parquet	40.1 MB	32%	0.74 sec	0.93 sec
	write_table, compression='snappy'		24.8 MB	58%	1.31 sec	0.95 sec
	write_table, compression='lz4'		24.7 MB	58%	0.79 sec	0.94 sec
	write_table, compression='zstd'		19.3 MB	67%	1.00 sec	0.98 sec
	write_table, compression='gzip'		18.8 MB	68%	5.07 sec	1.18 sec

읽기/쓰기 테스트 모두 AWS – EC2(m5.large-centos7) – gp2(100GB) 에서 진행 하였다.

parquet 을 생성한 이유는 파일을 읽을때 모든 컬럼인 index가 걸려있는것과 같이 빠르게 읽기 위함이니 읽기 테스트도 해본다.

#!/usr/bin/env python

# -*- coding: utf-8 -*-

import os

import time

import pandas as pd

import pyarrow as pa

import pyarrow.parquet as pq

from pyarrow import csv

def tsv2table2dataframe(filename, skiphead, column_length):

table_columns = [str(i) for i in range(0, column_length)]

r_opt = csv.ReadOptions(skip_rows=skiphead, column_names=table_columns, use_threads=False)

p_opt = csv.ParseOptions(delimiter='\t')

pyarrow_table = csv.read_csv(fname, read_options=r_opt, parse_options=p_opt)

t1 = str(round(time.time() - ts, 2))

ts2 = time.time()

pyarrow_df = pyarrow_table.to_pandas()

t2 = str(round(time.time() - ts2, 2))

return pyarrow_df, t1, t2

print('pyarrow version:', pa.__version__) # print pyarrow Version

fname = "sample/shjang_Genome_20191011.txt" # Target file (TSV)

sh = 4 # file header line.

cc = 10 # column count

out_format = 'gzip' # pyarrow 0.16 support: 'none', 'snappy', 'gzip', 'lz4', 'zstd'

print('File size: ' + str(os.path.getsize(fname)))

ts = time.time()

dataframe = pd.read_csv(fname, skiprows=sh, sep='\t', quotechar='"', header=None, index_col=None, error_bad_lines=False)

print('text TSV file read with pandas to dataframe: ' + str(round(time.time() - ts, 2)) + ' sec')

ts = time.time()

dataframe = pd.read_csv(fname+'.gz', compression='gzip', skiprows=sh, sep='\t', quotechar='"', header=None, index_col=None, error_bad_lines=False)

print('gzip TSV file read with pandas to dataframe: ' + str(round(time.time() - ts, 2)) + ' sec')

ts = time.time()

dataframe, t1, t2 = tsv2table2dataframe(fname, sh, cc)

print('text TSV read(' + t1 + ' sec) with pyarrow to dataframe(' + t2 + ' sec): ' + str(round(time.time() - ts, 2)) + ' sec')

ts = time.time()

dataframe, t1, t2 = tsv2table2dataframe(fname+'.gz', sh, cc)

print('gzip TSV read(' + t1 + ' sec) with pyarrow to dataframe(' + t2 + ' sec): ' + str(round(time.time() - ts, 2)) + ' sec')

exit(0)

TSV, parquet 파일 읽기 테스트 (pandas, pyarrow)

	def	ext	MB	processing time python 2.7	processing time python 3.6
pandas	read_csv	.txt	58.8 MB	1.39 sec	1.56 sec
	read_csv, compression='gzip'	.txt.gz	16.3 MB	1.68 sec	2.06 sec
	read_parquet	.parquet (none)	40.1 MB	0.72 sec	0.93 sec
		.parquet (snappy)	24.8 MB	1.03 sec	0.95 sec
		.parquet (lz4)	24.7 MB	0.73 sec	0.94 sec
		.parquet (zstd)	19.3 MB	0.76 sec	0.95 sec
		.parquet (gzip)	18.8 MB	0.96 sec	1.18 sec
pyarrow	read_csv, to_pandas	.txt	58.8 MB	1.01 sec	1.30 sec
	read_csv, to_pandas	.txt.gz	16.3 MB	1.41 sec	1.37 sec
	read_table, to_pandas	.parquet (none)	40.1 MB	0.69 sec	0.90 sec
		.parquet (snappy)	24.8 MB	0.99 sec	0.89 sec
		.parquet (lz4)	24.7 MB	0.69 sec	0.92 sec
		.parquet (zstd)	19.3 MB	0.75 sec	0.95 sec
		.parquet (gzip)	18.8 MB	0.95 sec	1.22sec

이 문서 처음에 언급 했다 시피 대용량 파일을 처리 하기 위함. 즉 “빅데이터”(HIVE, Presto, Spark, AWS-athena)환경을 위한 포멧이다.

모두 테스트 해보면 좋겠지만 아직 실력이 부족해서 AWS athena 만 테스트를 진행 한다.

구조적으로 S3 버킷에 parquet 파일을 넣어 두고 athena 에서 테이블을(S3 디렉토리 연결) 생성 하여 SQL 문으로 검색을 하는데 사용 한다.

TSV, parquet 파일 읽기 테스트 (AWS – athena)

	ROW FORMAT SERDE	ext	Searched MB	processing time (select target 2)	processing time (select target 50)
athena	org.apache.hadoop.hive. serde2.lazy. LazySimpleSerDe	.txt	58.8 MB	1.17 ~ 3.35 sec	1.86 ~ 2.68 sec
	org.apache.hadoop.hive. serde2.lazy. LazySimpleSerDe	.txt.gz	16.3 MB	1.37 ~ 1.49 sec	1.44 ~ 2.69 sec
	org.apache.hadoop.hive. ql.io.parquet.serde. ParquetHiveSerDe	.txt.parquet	10.48 MB	1.11 ~ 1.49 sec	1.00 ~ 1.38 sec
		.snappy.parquet	4.71 MB	0.90 ~ 2.36 sec	0.90 ~ 1.00 sec
	지원 불가	.lz4.parquet	지원 불가
	지원 불가	.zstd.parquet	지원 불가
	org.apache.hadoop.hive. ql.io.parquet.serde. ParquetHiveSerDe	.gzip.parquet	2.76 MB	0.89 ~ 1.17 sec	0.90 ~ 1.85 sec

읽는 속도가 향상되었고 스캔 크기가 적게 나온다. (parquet 의 강점을 보여주는 테스트-스캔비용의 절감이 가능.)

athena 테이블 생성에 사용된 DDL 쿼리문 (TSV, parquet)

CREATE EXTERNAL TABLE IF NOT EXISTS [데이터베이스명].[테이블명] (

`rsid` string,

`chr` string,

`pos` int,

`gt` string

)

ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'

STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat'

OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'

LOCATION 's3://[S3-URL]/[TSV폴더]';

CREATE EXTERNAL TABLE IF NOT EXISTS [데이터베이스명].[테이블명] (

`rsid` string,

`chr` string,

`pos` int,

`gt` string

)

ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'

WITH SERDEPROPERTIES ('serialization.format' = '1', 'parquet.column.index.access'='true')

LOCATION 's3://[S3-URL]/[parquet폴더]'

TBLPROPERTIES ('has_encrypted_data'='true');

PS. 이건 저도 어려 웠어요…..

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	~]# 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 (이거는 나중에 스스로 공부할때 사용할 키워드를 주절주절 써놓은것…)