측정항목별 그래프를 수십 개 늘어놓은 스몰 멀티플 형태의 대시보드가 열리는 데 한참 걸리고, 결국 "오류가 발생했습니다. 리포트를 표시할 수 없습니다." 가 뜬다. 편집 모드도 똑같이 느리다. CAS 메모리는 400GiB 제한에 2GiB 밖에 쓰지 않는다.
메모리 부족이면 CAS 파드가 제한에 붙어 있어야 한다. 먼저 실제 사용량을 본다.
kubectl get pod -n <namespace> | grep cas
kubectl top pod -n <namespace> | grep cas
kubectl -n <namespace> describe pod <cas-controller-pod> | grep -A3 Limits
인메모리 테이블 현황도 함께 본다.
proc cas;
table.tableInfo / caslib="<VA 가 쓰는 caslib>";
quit;
proc cas;
table.tableDetails / name="<테이블명>";
quit;
CAS 메모리가 거의 비어 있는 것은 좋은 신호가 아니다. 인메모리 분석을 거의 하지 않고 있다는 뜻일 수 있다. 리포트를 열 때마다 원천 DB 로 매번 쿼리가 나가는 구조라면 객체 수만큼 쿼리가 터진다.
Report 서비스 로그에 아래가 보이면 원인이 거의 잡힌다.
ddxprimary warning: dataTruncated
클라이언트 질의 행 제한이 서버 절사값을 초과하기 때문에 일부 데이터가 나타나지 않습니다.
한 객체가 요청한 행 수가 서버의 반환 제한을 넘어 결과가 잘리고 있다는 뜻이다. 메모리 문제가 아니라 요청 크기 문제다. 객체가 많으면 이런 요청이 동시에 수십 건 나가면서 누적 대기가 길어진다.
kubectl get pod -n <namespace> | egrep "visual|report|compute|cas"
kubectl logs -n <namespace> deploy/sas-visual-analytics --since=30m
kubectl logs -n <namespace> deploy/sas-report-execution --since=30m
서비스 이름은 릴리스마다 다르므로 kubectl get deploy -n <namespace> | grep -i report 로 먼저 확인한다.
브라우저 개발자 도구(F12) 의 Network 탭에서 가장 오래 걸린 요청 하나만 보면 갈린다.
| 관찰 | 해석 | 다음 행동 |
|---|---|---|
| 504 | 인그레스 또는 리포트 실행 타임아웃 | 타임아웃 값을 늘리고, 동시에 요청 크기를 줄인다 |
| 500 · 503 | 백엔드 서비스 또는 그 의존 서비스 장애 | 해당 서비스 로그를 본다 |
| 200 인데 화면이 멈춤 | 브라우저 렌더링 과부하 | 한 화면의 객체 수를 줄인다 |
브라우저 쪽이 의심되면 크롬·엣지의 작업 관리자(Shift + Esc) 에서 해당 탭의 CPU·메모리를 본다. 사양이 더 좋은 PC 에서 같은 리포트가 잘 열리면 서버가 아니라 클라이언트 문제다.
효과가 큰 순서다.
dataTruncated 가 사라진다.페이지를 요약·상세·이상치로 나누는 것만으로도 체감이 크게 달라진다. 스몰 멀티플을 그대로 두고 서버만 키우는 방향은 비용 대비 효과가 낮다.