Skip to content
isdnetworks
Go back

옮기기 직전 상태의 기록

시스템을 옮기고 나서 전보다 느려졌다는 말을 들었는데 전이 얼마였는지를 몰랐다. 측정한 적이 없었고 옮기는 데 급해서 옮기는 것만 했기 때문이다.

Table of contents

Open Table of contents

옮기기 전에 재는 다섯

다음 이관부터는 옮기기 전에 다섯 가지를 쟀다. 주요 화면의 응답 시간과 시간당 요청 수와 자원 사용률과 시간당 오류 수와 주요 테이블 건수다.

재는 데 한 시간이면 됐고 스크립트로 만들어 두니 옮긴 뒤에 같은 것을 돌려 비교할 수 있었다. 한 번만 재면 그날이 특이한 날일 수 있으므로 일주일치를 시간대별로 나눠 남기고 비교할 때 같은 시간대끼리 봤다.

설정과 자료의 스냅숏

설정도 함께 덤프해 남겼는데 런타임 판과 메모리 한도와 실행 시간 제한과 데이터베이스 버퍼 크기 같은 것들이다. 옮긴 뒤 값이 다르면 그것이 원인일 수 있다.

실제로 한 번 찾았는데 새 서버의 버퍼 풀이 기본값이었고 옛 값을 알고 있어서 바로 맞췄다. 자료는 건수만이 아니라 합계와 최대 식별자와 최소 및 최대 생성 시각도 남겼는데 건수가 같아도 내용이 다를 수 있기 때문이다.

무엇이 돌고 있었는지

예약 작업 목록과 실행 중인 서비스와 열려 있는 포트도 덤프해 뒀다. 옮긴 뒤 안 도는 것이 있는지를 대조하기 위해서다.

배치 하나가 안 옮겨진 것을 이것으로 찾았는데 월 1회 도는 것이라 안 돌아도 한 달간 몰랐을 것이다. 목록이 없었으면 그 배치의 존재 자체를 잊었을 것이다.

옮긴 뒤의 비교

옮긴 뒤 같은 스크립트를 돌려 비교하니 중앙값은 조금 늘고 상위 구간은 줄었으며 오류와 자원 사용률은 함께 내려갔다. 대부분이 조금 느려지고 느리던 것이 빨라진 형태였다.

숫자가 있으니 느려졌다는 말에 정확히 답할 수 있었다. 기록을 한 폴더에 모아 두니 다음 이관에서 그 구조를 그대로 썼다.

되돌릴 때 쓰인 기록

한 번은 옮기고 나서 큰 문제가 생겨 되돌려야 했다. 되돌리면서 옛 설정을 맞춰야 하는데 그 사이 며칠 동안 옛 서버 설정을 여기저기 바꿔 놓은 상태였다.

옮기면서 옛 서버 자원을 줄여 놓았던 것이라 되돌리려면 다시 올려야 했고 기록이 있어서 원래 값을 알 수 있었다. 옮기기 전 기록은 옮긴 뒤 비교용만이 아니라 되돌릴 때 원래 값을 아는 근거로도 쓰였다.

정리


Share this post on:

Previous Post
청크마다 반복되는 즉시 로딩
Next Post
대상마다 다른 저장 자리와 형식