SAS Studio 에서 같은 코드를 혼자 돌리면 4분에 끝나는데 열세 명이 동시에 돌리면 20분이 걸린다. 그런데 뒷단 DB(SingleStore 계열 SpeedyStore) 의 CPU·메모리는 시작 5분 만에 뚝 떨어지고, Compute 세션 노드의 CPU·메모리도 30% 를 넘지 않는다. 20분이 지나서야 사용자별로 결과가 하나씩 튀어나온다.
DB 의 CPU 가 먼저 빠졌다는 것은 연산이 이미 끝났다는 뜻이다. 디스크 I/O 병목이라면 CPU 가 먼저 떨어지지 않고 iowait 이 올라간 채로 유지된다. Compute 노드의 CPU·메모리가 30% 아래라는 것도 연산 자원이 남아 있다는 뜻이다.
I/O 병목인지 가르려면 아래 중 둘 이상이 함께 관찰돼야 한다. 하나도 맞지 않으면 I/O 는 원인이 아니다.
iostat -x 1 # await 급증 여부
vmstat 1 # wa 10% 이상 지속 여부
nfsstat -c # NFS 재전송·지연
Viya 4 에서 DB 연산이 끝난 뒤에도 남는 구간이 있다. 이 구간은 세션 단위로 직렬 처리된다.
Studio → Compute Session → CAS → 외부 DB (여기까지는 병렬, 빠름)
↓
결과 Fetch → SAS 포맷 변환 → ODS/HTML 생성 → Studio 렌더링 (직렬, 병목)
DB 는 계산만 하고, 결과를 SAS 데이터셋과 ODS 출력으로 바꾸는 일은 Viya 가 한다. 4천만 행짜리 결과를 열세 명이 동시에 받아 가면 이 변환·전달 구간에 줄이 선다. CPU 사용률이 낮은데도 체감이 느린 전형적인 모습이다.
우선순위가 높은 원인 세 가지다.
| 순위 | 원인 | 확인 방법 |
|---|---|---|
| 1 | ODS·HTML 결과 생성 — Studio 는 결과를 다 만든 뒤에야 화면에 올린다 | 출력을 끄고 같은 코드를 돌려 시간을 비교한다 |
| 2 | CAS → Compute 결과 Fetch 직렬화 — proc print, select *, table.fetch |
결과를 화면에 내지 않고 CAS 테이블로만 남겨 비교한다 |
| 3 | Compute context 동시성 제한 — 세션 파드 수와 결과 처리 스레드 제한 | 동시 세션 수를 줄여 가며 시간 변화를 본다 |
가장 효과가 큰 것은 화면 출력을 줄이는 것이다. 결과를 CAS 테이블로만 남기면 변환·전달 구간 자체가 사라진다.
proc sql;
create table casuser.tmp as
select ... ;
quit;
미리보기가 필요하면 행 수를 제한한다.
options obs=1000;
proc print data=casuser.tmp(obs=100); run;
ODS 출력을 쓰지 않는 배치성 작업은 아예 닫아 둔다.
ods _all_ close;
구조적으로는 Compute context 를 대화형과 배치용으로 갈라 두고, 동시 사용자 수에 맞춰 세션 파드 수를 조정한다. 관련 설정 위치는 SAS Viya 4 Compute 세션 에 있다.
Viya 4 는 대부분의 PVC 를 NFS 로 받는다. 노드 인터커넥트가 1GbE 면 이론 최대가 약 125 MB/s 라 CAS 디스크 캐시, SASWORK, 리포트 데이터가 모두 이 대역을 나눠 쓰게 된다. 파드 수가 많고 NFS PVC 가 많은 구성에서는 10GbE 와의 차이가 그대로 체감으로 온다.
다만 위 증상처럼 DB 와 Compute 양쪽 자원이 모두 놀고 있는 경우는 대역 문제가 아니다. 네트워크를 올리기 전에 결과 반환 구간부터 줄여야 한다. 순서를 바꾸면 돈을 쓰고도 같은 시간이 나온다.