gridcenter-cap을 통한 fluent해석 성능 및 처리량 분석...

22
1/22 페이지 GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서 ㈜POSCO 기술연구소 컨설팅 보고서 본 자료는 ㈜클루닉스에서 ㈜POSCO 기술 연구소의 요청에 의해 자사 통합 해석 시 스템 구성 제품인 GridCenter-CAP을 이용하여 Fluent 유동 해석 성능과 작업 처리 량에 대한 분석 보고서입니다. ㈜클루닉스의 협의 없이 발췌 및 배포를 금합니다. BMT 환경: GridCenter-CAP, GridCenter-HPC BMT S/W : Fluent CFD BMT 주관 : 클루닉스 기술부 BMT 일자 : 2009년 03월 20일~2009년 03월 31일 시스템 구축 밑 튜닝: 클루닉스 기술부/수석 컨설턴트 서 진우 CAE 어플리케이션 구축 및 튜닝 : 클루닉스 기술부/수석 컨설턴트 서 진우

Upload: others

Post on 29-Apr-2021

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

1/22 페이지

GridCenter-CAP을 통한 Fluent해석

성능 및 처리량 분석 보고서

㈜POSCO 기술연구소 컨설팅 보고서

본 자료는 ㈜클루닉스에서 ㈜POSCO 기술 연구소의 요청에 의해 자사 통합 해석 시

스템 구성 제품인 GridCenter-CAP을 이용하여 Fluent 유동 해석 성능과 작업 처리

량에 대한 분석 보고서입니다. ㈜클루닉스의 협의 없이 발췌 및 배포를 금합니다.

BMT 환경: GridCenter-CAP, GridCenter-HPC

BMT S/W : Fluent CFD

BMT 주관 : 클루닉스 기술부

BMT 일자 : 2009년 03월 20일~2009년 03월 31일

시스템 구축 밑 튜닝: 클루닉스 기술부/수석 컨설턴트 서 진우

CAE 어플리케이션 구축 및 튜닝 : 클루닉스 기술부/수석 컨설턴트 서 진우

Page 2: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

2/22 페이지

목차

1. BMT 요약

2. BMT 환경 정보

3. BMT 주요 시나리오 소개

4. BMT 항목 별 결과 및 세부 분석

5. BMT 결론

첨부 : GridCenter-CAP를 통한 BMT 진행 주요 화면 자료

Page 3: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

3/22 페이지

1. BMT 요약

본 BMT는 ㈜POSCO 기술연구소의 요청에 의해 기업 내 연구실 별로 분산된 해석 환경을

중앙으로 통합 재 구성 할 경우, 해석 처리 성능의 개선 효과를 예측하고, 동시 처리

작업량 측면에서의 최적의 통합 자원 할당 조건을 파악했다. 그런 후 테스트를 통해,

현 ㈜POSCO 해석 환경을 시스템 통합 환경으로 전환할 경우, 해석 S/W 라이센스 활용도

와 해석 처리 성능(해석 작업 생산성)의 개선에 대한 기대효과를 예측하고자 한다.

본 BMT는 ㈜POSCO 기술연구소에서 가장 많이 사용하는 해석 S/W인 Fluent의 2가지

Sample 예제를 이용하여 진행되었다.

Fluent 해석의 경우 여러 개의 Processor를 이용한 병렬 처리의 효과는 매우 우수하지

만, 단일 서버에서 여러 개의 해석을 동시에 수행할 경우 전체적인 해석 성능 저하가

매우 크다는 것을 확인하였다.

32core의 processor를 이용한 해석의 경우 단일 core 대비 평균 12배 이상의 해석 시간

단축이 확인되었다. 하지만 동시 처리 작업 시 가장 부적절한 자원 할당 조건에서는 해

석 시간이 93배 더 소모되었다.

본 BMT 결과 분석 내용과 사전에 파악된 ㈜POSCO의 자원 사용 현황 정보를 근거로 통합

의 기대효과를 산출하면, 5.3배의 평균 해석 응답 대기 시간 단축과 23배의 작업 생산

성(라이센스활용도) 향상, 17배의 서버 가용성 향상이 측정되었다.

본 요약은 이번 BMT의 결과만을 요약한 것으로, 요약에 대한 세부 근거는 “4. BMT 항

목별 결과 및 세부 분석”을 참고하길 바란다.

Page 4: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

4/22 페이지

2. BMT 환경 정보

- H/W 구성 정보

세부 사양 자원 수

Cpu Intel(R) Xeon(TM) Quad E5420 CPU 2.5GHz 2cpu(8core)

Memory DIMM Synchronous 667 MHz 2GByte 4개 (16Gbyte)

Hard disk SAS DELL 230GByte 1개 (160Gbyte)

Network BM NetXtreme II BCM5708 Gigabit Ethernet 2port

nodes Dell (PowerEdge) 4 nodes

기본 BMT 진행은 클루닉스 사내의 준비된 32core(4 nodes) 규모의 HPC 시스템에서

BMT를 진행함.

- S/W 구성 정보

S/W 명 S/W 버전

운영체제 Redhat Eenterprise Server(x86_64) V4-update5

HPC 구축 S/W GridCenter 1.9

HPC 운영 S/W GridCenter-HPC, 1.9

HPC 최적화 S/W GridCEnter-CAP 1.9

해석 S/W Fluent 6.3.26

해석 예제 Test1_Turb.cas / Test2_Lam.cas

본 BMT에 사용된 HPC 환경 구축 및 해석 작업 실행과 성능 최적화 프로그램으로는 ㈜

클루닉스에서 개발한 GridCenter 제품 군을 사용하였고, BMT에 사용된 예제는 ㈜

POSCO 기술 연구소에서 제공되었다.

Page 5: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

5/22 페이지

3. BMT 주요 시나리오

본 BMT 진행 주요 절차는 아래와 같다.

BMT는 우선적으로 BMT 환경 구축 후 초기 구축 환경에서 제공 받은 예제에 대한 기본

테스트를 시행한다. 기본 테스트에서는 예제에 대한 무결성 검증 및 해석 실행 조건을

파악하였다. 그 후 Fluent 해석 수행 환경 및 시스템 환경을 최적화하고, 최종적으로

정해진 시나리오에 의해 테스트를 진행하였다.

본 테스트에 사용된 예제는 아래와 같다.

해석조건 정밀도 반복횟수

Test1_Turb.cas Steady 3d double precision 5000회

Test2_Lam.cas Steady 3d double precision 1000회

본 테스트에서 실시된 BMT 항목은 아래와 같다.

BMT-1 : Fluent 병렬 처리 Scalability 성능 테스트

1~32 CPU(core) 증가에 따른 Fluent 병렬 해석 실행 시간 측정

BMT-2 : Fluent 동시 처리 작업(Throughput) 성능 테스트

자원 할당 조건 별 동시 처리 작업 실행 시간 측정

BMT-3 : ㈜POSCO 유사 해석 환경에서 동시 처리 작업 성능 테스트

해석 작업 생산량 및 해석 S/W 라이센스 활용 기대 효과 분석

위 테스트 항목의 결과를 근거로 현 ㈜POSCO 해석 환경과 도입 예상 환경에 대해 아래

항목들을 비교하고자 한다.

Page 6: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

6/22 페이지

항목 내용

개별 작업 처리 시간 개별 작업의 해석 처리 시간

전체 작업 처리 시간 특정 시간 내에 여러 명의 사용자가 제출한 다수의 작업

을 모두 처리하는데 소요된 전체 시간

평균 응답 대기 시간 특정 시간 내에 여러 명의 사용자가 다수의 작업을 동시

제출할 경우 본인의 작업이 완료되는 것을 기대하는 평균

작업 처리 시간

작업 생산성(라이센스) 일정 기간, 같은 수의 작업에 사용된 라이센스 사용 전체

시간 측정

작업 생산성(가용서버) 일정 기간, 같은 수의 작업에 사용된 CPU 사용 전체 시간

측정

Page 7: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

7/22 페이지

4. BMT 항목 별 결과 및 세부 분석

BMT-1 : Fluent 병렬 처리 Scalability 성능 테스트

본 테스트는 Fluent 해석 시 Processor(CPU) 수를 지속적으로 증가시키며, 해석 처리

시간을 측정하여, 결과를 통해 Fluent 병렬 처리 해석 시 어느 정도의 성능 개선이 기

대되는지를 예측하고자 한다.

아래는 첫 번째 예제인 “TEST1_TURB.CAS”에 대한 테스트 결과 이다.

[예제: Test1_Turb.cas, Elapsed 단위:second]

Core 수 1 2 4 8 16 32

Elapsed 9752 5012 4745 776 1603 232

Speedup 1 1.9 2.1 12 6 42

Test1_Turb 병렬 계산 성능 결과

0

2000

4000

6000

8000

10000

12000

1 2 4 8 16 32

number of cores

Ele

psed

Tim

e(se

c)

0

5

10

15

20

25

30

35

40

45

spee

dup

ElapsedSpeedup

Test1_turb.cas 예제의 경우 1개 프로세서를 이용한 해석 속도에 비해 32개 프로세서를

이용한 경우 최대 42배의 성능 개선이 확인되었다. 본 예제의 경우 해석 모델에 대한

Processor Partition 조건에 따라 iteration 시 “reversed flow in faces on pressure-

outlet”증세가 나타나며, 결과 수렴에 필요한 iteration수가 증가되는 현상이 발생했다.

Page 8: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

8/22 페이지

“reversed flow” 증세가 발견된 core 수는 1, 4, 16으로, 수렴에 필요한 iteration 수

는 1100~1300회 이다. 하지만 8core, 32core를 통한 해석 시엔 해당 증세가 나타나지 않

고, iteration 250~350 회 사이에서 결과가 수렴되어 core수 증가에 따른 규칙적인 성능

개선이 관측되었다.

위 테스트 결과로는 실행 core 수와 해석 성능의 상관 관계를 파악할 수 없기 때문에,

Core 수를 증가 시키며, 각 core 수에서의“Average wall-clock time per iteration”을

다시 측정하였다. 아래는 그 결과이다.

[예제: Test1_Turb.cas, TPI: Time per iteration]

Core 수 1 2 4 8 16 32

TPI 8.6 4.64 4.17 2.64 1.31 0.69

Speedup 1 1.85 2.1 3.3 6.6 12.4

Core 증가별 Iteration 개별 처리 속도 결과

0

1

2

3

4

5

6

7

8

9

10

1 2 4 8 16 32

number of cores

Ele

psed

Tim

e (s

ec)

0

2

4

6

8

10

12

14sp

eedu

p

TPISpeedup

테스트 결과 해석에 사용된 core 수를 증가할수록, iteration 별 해석 처리 속도가 지

속적으로 빨라지는 것을 확인할 수 있다.

32core 해석 시 1개 core 해석 대비 최대 12.4배의 iteration 별 해석 속도 개선이 확

인 되었다.

Page 9: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

9/22 페이지

다음은 두 번째 예제를 가지고, 동일한 테스트를 진행한 결과이다.

[예제: Test2_Lam.cas, 단위:second]

Core 수 1 2 4 8 16 32

Elapsed 5949 3122 2756 1708 871 498

Speedup 1 1.9 2.1 3.4 6.8 12

Test2_Lam 병렬 계산 성능 결과

0

1000

2000

3000

4000

5000

6000

7000

1 2 4 8 16 32

number of cores

Ela

psed

Tim

e (s

ec)

0

2

4

6

8

10

12

14

spee

dup

ElapsedSpeedup

Test2_Lam 예제의 경우 32core 해석 시 1개 core 해석 대비 최대 12배의 성능 개선이

확인되었다.

㈜POSCO에서 제공 받은 Fluent 예제의 경우 매우 병렬 처리 효과가 우수한 예제에 해당

한다. 동일 환경으로 일반 예제를 가지고, Fluent 병렬 계산을 수행한 경우 대부분

8~10배 정도의 성능 개선이 측정되지만, ㈜POSCO 제공 예제의 경우 12배 이상의 성능

개선이 측정되었다. 그러므로 통합 해석 시스템을 도입할 경우 일반적인 Fluent 해석

보다 30%이상 높은 병렬 처리 효과가 기대된다.

BMT-2 : Fluent 동시 처리 작업(Throughput) 성능 테스트

본 테스트는 8core가 장착된 서버 4대(총 32core)를 통합 해석 환경으로 구성하여, 1회

해석 시 할당 core수와 동시 작업 수 등의 제출 가능 작업 환경을 파악하고, 각 작업

환경 별“개별 해석 처리 속도”,”작업 동시 처리 속도”,“동시 작업 가능 수”,

“라이센스 사용 수”등을 측정한 것이다.

또한 본 테스트 결과를 통해 “작업 처리 시간”, “평균 응답 대기 시간”, “작업

생산성(라이센스기준, 가용서버기준)”등을 산출하였다.

Page 10: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

10/22 페이지

[처리 속도 단위 : 초]

CASE 별 작업실행형태

계산

방식 CASE 명 Core

서버

작업

전체

동시

실행

작업수

실행

횟수

동시

사용

라이센

스수

1회

실행

작업

속도

전체

작업

처리

속도

CASE1 1 1 1 4 8 4 5949 47592

CASE2 2 1 1 4 8 8 3122 24976

CASE3 4 1 1 4 8 16 2756 22048

CASE4 8 1 1 4 8 32 1708 13664

CASE5 1 1 8 32 1 32 46586 46586

CASE6 2 1 4 16 2 32 30670 61340

CASE7 4 1 2 8 4 32 11097 44388

CASE8 1 1 4 16 2 16 23434 46868

SMP

CASE9 2 1 2 8 4 16 11506 46024

CASE10 1 2 4 8 4 16 20992 83968

CASE11 2 2 2 4 8 16 10608 84864

CASE12 1 4 4 4 8 16 22252 178016

CASE13 2 4 2 2 16 16 11347 181552

CASE14 8 4 1 1 32 32 498 15936

CASE15 8 2 1 2 16 32 871 13936

CASE16 4 4 1 1 32 16 777 24864

MPP

CASE17 4 2 1 2 16 16 1441 23056

위 결과 중 전체 작업 처리 시간 측정 방식은 아래와 같다.

본 테스트 결과를 보면 Fluent 해석의 경우 core 수 증가에 따른 성능 개선 효과는 매

우 우수하나, 동일 장비 내에서의 2개 이상의 작업이 동시에 수행될 경우, 매우 극심한

성능 저하가 나타나는 것을 측정하였다. CASE3 과 CASE7의 결과를 비교해 보면, 1대 서

버에서 4core를 할당한 해석 작업 1개가 수행되는 시간은 45분이다. 하지만 1대 서버에

Page 11: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

11/22 페이지

서 4core를 할당한 해석작업 2개를 동시에 수행하면, 실행 시간이 두 배 이상(4배) 소

요되는 것을 확인 할 수 있다.

더 심한 경우는 CASE14:(8+8+8+8)x1 과 CASE5:(1)x8의 조건 비교이다. CASE14은 단일

성능 중심에서 최선의 조합이다. CASE5조합은 적절한 자원 할당 정책이 없는 경우 흔히

많이 사용되는 조건이다. 이 두 조건에서의 동일 예제에 대한 개별 해석 처리 시간 차

이는 93배 이상 나타난다.

이러한 이유로 통합 방식의 Fluent 해석 환경 구축 시에는 작업의 중요성과 동시 처리

요구량 등을 고려하여, 조직 환경에 최적화된 자원 할당 정책이 적용되어야 할 필요가

있다.

작업 환경별 처리 성능 비교

0 20000 40000 60000 80000 100000 120000 140000 160000 180000 200000

CASE1

CASE2

CASE3

CASE4

CASE5

CASE6

CASE7

CASE8

CASE9

CASE10

CASE11

CASE12

CASE13

CASE14

CASE15

CASE16

CASE17

환경

분류

.

Elapsed Time(sec)

전체 작업처리속도

1회 실행작업속도

아래는 위 테스트 결과를 근거로 Fluent License 32개, 총 가용 서버 수 4대, 총 가용

core 수 32개의 작업 실행 환경에서 32개의 작업을 동시 처리하는데, 가장 적절한 자원

할당 조건과 가장 부적절한 자원 할당 조건의 성능과 처리량(생산성)을 비교한 것이다.

Page 12: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

12/22 페이지

적절조합:CASE4 부적절조합:CASE5 개선도

개별 작업 처리 시간 28분 13시간 27배

평균 응답 대기 시간 2시간8분 13시간 6.1배

작업 생산성(라이센스) 51.2 1.8 28배

작업 생산성(가용서버) 51.2 1.8 28배

- 개별 작업 처리 시간 : 작업 별 해석 수행 시간

- 응답 대기 시간 : 32개 작업이 동시 제출 시 작업 별 평균 처리 시간

- 작업 생산성(라이센스) : 총 가용 라이센스(32개) 기준에서 1일 작업 생산성

- 작업 처리량(가용서버) : 총 가용 서버(8corex4) 기준에서의 1일 작업 생산성

생산성 측정 산출 방식

생산성 = [자원 총 가용시간] / [자원 총 소모시간]

32개 라이센스의 1일 총 가용 시간 = 32(license) x 24(hour)

32core 통합 시스템의 1일 총 서버 가용 시간 = 32(core) x 24(hour)

(8)x1 의 작업 생산성(라이센스) = 768시간 / (1708초 x 32 = 15시간)

(1)x8 의 작업 생산성(라이센스) = 768시간 / (46586초 x 32 = 414시간)

본 테스트 결과 동일한 자원 확보 상태에서 작업에 할당되는 자원 할당 조건에 따라 최

대 13배 이상의 동시 처리 작업(응답대기)속도의 차이가 나타나는 걸로 확인되었고, 1

일 동안 보유 자원(라이센스) 총 가용 시간 측면에서, 28배의 전체 작업 생산량 차이를

내는 걸로 확인 되었다. 최적의 효율을 보인 자원 할당 조건은 서버 당 8개 core를 이

용하여 1개의 fluent 해석 작업을 4대 서버에서 동시에 수행한 CASE4:(8)x1경우로 측정

되었다. 처리 시간 측면에서 가장 부적절한 조건은 CASE12:(1+1+1+1)x4 이고, 생산량

측면에서 가장 부적절한 조건은 CASE5:(1)x8로 측정되었다.

Page 13: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

13/22 페이지

BMT-3 : ㈜POSCO 유사 해석 환경에서의 동시 처리 작업 성능 테스트

본 테스트는 현재 24개의 Fluent 라이센스를 보유한 ㈜POSCO 해석 환경과 유사한 기준

에서, 최적 자원 할당 조건을 분석한 결과이다. 테스트 조건은 8core 서버 6대에 전체

작업 수는 총 48개를 기준으로 하여 진행되었다. 결과는 아래와 같다.

CASE 별 작업실행환경

계산

방식 CASE 명 Core

서버

작업

동시

실행

작업수

실행

횟수

동시

사용

라이센

스수

1회

실행

작업

속도

전체

작업

처리

속도

CASE1 1 1 1 6 8 6 5949 47592

CASE2 2 1 1 6 8 12 3122 24976

CASE3 4 1 1 6 8 24 2756 22048

CASE4 8 1 1 3 16 24 1708 27328

CASE5 1 1 8 24 2 24 46586 93172

CASE6 2 1 4 12 2 24 30670 61340

CASE7 4 1 2 6 4 24 11097 44388

CASE8 1 1 4 24 2 24 23434 46868

SMP

CASE9 2 1 2 6 8 24 11506 92048

CASE10 1 2 4 12 4 24 20992 83968

CASE11 2 2 2 6 8 24 10608 84864

CASE12 1 4 4 4 12 16 22252 267024

CASE13 2 4 2 2 24 16 11347 272328

CASE14 8 3 1 1 48 24 713 34224

CASE15 4 4 1 1 48 16 777 37296

MPP

CASE16 4 2 1 2 24 16 1441 34584

적절조합:CASE3 부적절조합:CASE5 개선도

개별 작업 처리 시간 46분 13시간 17배

평균 응답 대기 시간 3시간20분 19시간30분 5.85배

작업 생산성(라이센스) 20.6 1.2 17.2배

작업 생산성(가용서버) 31.1 1.9 16.3배

Page 14: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

14/22 페이지

- 개별 작업 처리 시간 : 작업 별 해석 수행 시간

- 응답 대기 시간 : 48개 작업 동시 제출 시 평균 응답 대기 시간

- 작업 생산성(라이센스) : 총 가용 라이센스(24개) 기준에서 1일 작업 생산성

- 작업 생산성(가용서버) : 총 가용 서버 기준(8corex6)에서의 1일 작업 생산성

작업 환경 별 처리 성능 비교

0 50000 100000 150000 200000 250000 300000

CASE1

CASE2

CASE3

CASE4

CASE5

CASE6

CASE7

CASE8

CASE9

CASE10

CASE11

CASE12

CASE13

CASE14

CASE15

CASE16

작업

환경

분류

.

Elapsed Time (sec)

전체 작업처리속도

1회 실행작업속도

본 테스트 결과 자원 할당 조건에 따라 최대 12배 이상의 동시 처리 작업 속도 차이가

나타나는 것으로 확인되었고, 1일 동안 보유 자원(라이센스)의 총 가용시간 기준에서,

17.2배의 전체 작업 처리량(생산량) 차이를 내는 것으로 확인되었다. 최적의 효율을 나

타낸 자원 할당 조건은 단일 서버에서 4개 core를 이용한 1개의 fluent 작업을 수행한

CASE3:(4)x1 경우로 측정되었다. 처리 시간 측면에서 가장 부적절한 조건은

CASE12:(1+1+1+1)x4 이고, 생산량 측면에서 가장 부적절한 조건은 CASE5:(1)x8로 파악

되었다.

Page 15: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

15/22 페이지

해석 작업 생산량 및 해석 S/W 라이센스 활용 기대 효과

본문은 상위 테스트 결과와 BMT 사전 조사 내용을 근거로 하여, 연구실 별로 분산된 해

석 시스템 환경(현 ㈜POSCO 해석 환경)을 중앙으로 통합할 경우 해석 처리 성능과 전체

작업 처리량, 그리고 고가의 해석 S/W 라이센스 활용도 개선에 대한 기대 효과를 예측

한 결과이다.

본 분석에 앞서 BMT 사전 조사 시 파악된 ㈜POSCO의 Fluent 해석 환경은 아래와 같다.

라이센스수 서버수 해석당평균소요시간 해석건수/월 사용시간/월

총사용 24 9 17.8 시간 196 3,500

한달 기준의 위 조사 내용을 축소하여, 일 주일 동안의 자원 활용도를 산출하면 아래와

같다.

- 현 POSCO 환경 샘플

라이센스수 서버수 해석당평균소요시간 해석건수/7일 사용시간/7일

총사용 24 9 17.8 시간 48 858

그리고, BMT 사전 조사에서 파악된 ㈜POSCO 기술 연구 환경에 가까운 자원 할당 방식은

1~2개 정도의 core를 이용한 단일 해석 작업을 동일 서버에 여러 개 동시에 제출 하는

경우로, BMT-3에서 CASE5:(1)x8 혹은 CASE6:(2)x4의 조건과 유사하다.

- 현 POSCO 자원 할당 모델 : CASE5: (1) x 8 조건 결과

위 2개의 정보를 현 ㈜POSCO 해석 환경에서의 대표CASE라 가정하고, BMT-3에서

CASE3(적절조합)의 결과를 통합해석시스템(도입예상시스템)의 성능 수치로 가정 하여,

해석당 평균 소요 시간, 작업 생산성 등의 관심사항들을 비교를 하였다.

- 통합 해석 환경 성능 지표 : CASE 3: (4)x1 조건

라이센스수 서버수 해석당평균소요시간 해석건수/7일 사용시간/7일

총사용 24 6 3.3 시간 48 36.7 시간

결과는 아래와 같다.

Page 16: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

16/22 페이지

현 ㈜POSCO 환경 샘플 통합해석환경 개선도

개별 작업 처리 시간 17.8시간 46분 23배

평균 응답 대기 시간 17.8시간 3시간20분 5.3배

작업 생산성(라이센스) 4.7 108.9 23배

작업 처리량(가용서버) 14.1 217.9 15.4배

생산성 = [자원 총 가용시간] / [자원 총 사용시간]

라이센스 총 가용 시간(POSCO) = 24(license) x 24(hour) x 7(day)

서버 총 가용 시간(POSCO) = 8(core) x 9(node) x 24(hour) x 7(day)

BMT 서버 총 가용 시간 = 8(core) x 6(node) x 24(hour) x 7(day)

POSCO 해석 환경의 작업 생산성(라이센스) = (4032 / (17.8 x 48 = 854)) = 4.7

BMT 환경의 작업 생산성(라이센스) = (4032 / (0.77 x 48 = 36.96 )) = 108.9

현 ㈜POSCO 자원 할당모델 도입 예상 환경 개선도

개별 작업 처리 시간 13시간 46분 17배

평균 응답 대기 시간 19시간30분 3시간20분 5.85배

작업 생산성(라이센스) 1.2 20.6 17.2배

작업 생산성(가용서버) 1.9 31.1 16.3배

본 분석 결과 최적의 통합 해석 환경을 도입할 경우 단일 해석 작업의 처리 속도는

17~23배 개선이 예측되고, 여러 개의 작업을 여러 명의 연구원이 동시에 수행할 경우 6

배 정도 빠른 결과를 제공 받을 수 있을 것이라 예측된다. 또한 가용한 라이센스 사용

시간을 기준으로 생산성을 평가해 보면, 17배 정도의 생산성 향상이 측정되었다. 마지

막으로 도입된 시스템 장비(CPU)의 총 가용 시간을 기준으로 생산성을 측정한 결과 16

배의 개선이 예측 된다.

Page 17: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

17/22 페이지

5. BMT 결론

본 BMT를 통해 Fluent 해석의 경우, 단일 서버 내 동시 작업을 규제하고, 적절한 수의

core를 이용하여 병렬 처리 작업을 수행하는 것이 가장 효율적인 작업 형태라는 것을

확인할 수 있었다.

32core의 processor를 이용한 해석의 경우 단일 core 대비 평균 12배 이상의 해석 시간

단축이 확인되었다. 하지만 동시 처리 작업 시 가장 부적절한 자원 할당 조건에서는 해

석 시간이 93배 더 소모되었다.

본 테스트를 통해 알 수 있듯이 통합 해석 시스템 도입에서 가장 중요한 요소는 각 조

직의 해석 실행 환경에 최적화된 자원 할당 정책 적용 이다.

㈜POSCO 기술 연구소 환경에 가장 적절한 자원 할당 정책이 적용된 통합 해석 환경을

도입하면, Fluent 해석의 경우 현재에 비해 23배의 작업 생산성(라이센스기준) 향상과

5배 이상의 평균 응답 대기 시간 단축이 기대된다.

Page 18: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

18/22 페이지

첨부 : GridCenter-CAP를 통한 BMT 진행 주요 화면 자료

- Test1_Turb.cas 해석 작업 제출 화면

- Test2_Lam.cas 해석 작업 제출 화면

Page 19: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

19/22 페이지

- BMT 관련 해석 작업 검색 화면

Page 20: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

20/22 페이지

- GridCenter-CAP 초기 로그인 화면

- Fluent 해석 작업 상태 모니터링 화면

Page 21: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

21/22 페이지

- Fluent 해석 작업 실시간 로그 모니터링 화면

Page 22: GridCenter-CAP을 통한 Fluent해석 성능 및 처리량 분석 보고서syszone.co.kr/PDF/posco_report1.pdf · 위 결과 중 전체 작업 처리 시간 측정 방식은 아래와

22/22 페이지

- Fluent 해석 시 실시간 프로세스 모니터링 화면

- GridCenter-CAP 통합 자원 모니터링 화면