1. 화면이 뒤섞는 네 가지 상태 구분하기
연결이 열려 있다는 것은 아직 머신과 대화할 수 있다는 것만 증명합니다. 보이는 터미널이 계산이 이미 끝난 셸을 호스팅하고 있을 수도 있습니다. 반대로 연결이 끊겼다고 해서 프로세스가 중단되었다고 단정할 수 없습니다. 따라서 먼저 실행과 그 흔적을 찾을 위치에 이름을 붙이는 것부터 시작하세요.
프로세스의 존재, 업무 진행 상황, 결과 승인을 각각 별도로 추적하세요. 로그의 줄 수는 성공적으로 처리된 데이터의 카운터가 아닙니다. 프로그램이 같은 경고를 반복할 수도 있습니다. 부분 출력은 읽을 수 있더라도 불완전할 수 있습니다.
이 방법은 필요한 접근 수단을 이미 받아 확인했다고 가정합니다. 특정 접근 프로토콜이나 파일의 자동 보존을 약속하지 않습니다. 사용 가능한 도구와 목적지는 실제로 제공된 환경에서 확인해야 합니다.
표의 모든 열을 보려면 스크롤하세요.| 관찰 | 이것이 나타내는 것 | 이것이 증명하지 않는 것 |
|---|---|---|
| 활성 연결 | 채널이 응답합니다. | 계산이 진행되고 있습니다. |
| 프로세스 존재 | 실행이 아직 존재합니다. | 올바른 항목을 처리하고 있습니다. |
| 검증된 카운터 증가 | 예정된 단위가 완료되었습니다. | 전체 코퍼스가 완료되었습니다. |
| 반환 코드가 0인 경우 | 프로그램이 정상 종료를 알립니다. | 결과가 계약을 준수합니다. |
| 통제된 출력 회수 완료 | 선정된 기준이 검증되었습니다. | 이 기준을 넘어서는 품질 |
2. 분리하기 전에 식별 가능한 실행 준비하기
데이터, 실제 구성, 애플리케이션의 짧은 초기 실행을 확인하세요. GPU 진단은 다른 질문에 답합니다. 백엔드가 계산을 실행할 수 있는가? 전체 코퍼스 로딩이나 프로그램 로직을 검증하지는 않습니다. 긴 시간의 실행을 시작하기 전에 이러한 검사를 수행하세요.
실행 식별자와 새 폴더를 선택하세요. 시크릿이 없는 명령, 코드 버전, 입력의 정체성, 예상 결과를 보관하세요. 로그를 기록할 위치와 파일을 회수할 위치를 정하세요. 두 개의 실행이 동시에 같은 폴더에 쓰면 안 됩니다.
독립적인 파티션으로 나뉜 작업의 경우, 파티션이 언제 완료되는지 정하세요. 계산 완료, 파일 닫힘, 내용 확인, 상태 저장. 쓰기 중인 파일은 승인된 결과와 같은 의미를 가져서는 안 됩니다. 시작 전에 실제로 사용 가능한 공간도 확인하세요.
3. 상황이 허락할 때 다시 찾을 수 있는 터미널 유지하기
환경에서 Unix 셸과 tmux를 제공한다면, 이 멀티플렉서를 사용하면 터미널을 분리했다가 재접속 후 다시 찾을 수 있습니다. 이는 연결 클라이언트 손실로부터 이 과정을 보호하지만, 머신 재시작이나 프로세스 소멸 후의 복구 메커니즘은 아닙니다.
아래 명령어는 교육용이며 실행되지 않습니다. Bash, tmux, 그리고 표시된 옵션을 가진 사용자의 traitement.py 프로그램을 전제로 하며, 이 파일은 제공되는 리소스가 아닙니다. 먼저 해당 프로그램의 짧은 명령을 확인하고, 두 계산을 혼동하지 않도록 별도의 세션 이름을 사용하세요.
세션을 만든 다음, 그 안에서 두 번째 블록을 실행하세요. 폴더 생성은 이미 존재하면 실패하며, 이는 로그를 조용히 재사용하는 것을 방지합니다. 셸이 쓰기 단계에 도달하면 반환 코드가 보존되지만, 갑작스러운 중단은 이 파일 생성을 막을 수 있습니다. 따라서 코드의 부재가 암묵적인 성공을 의미하지는 않습니다.
기본 단축키에서는 Ctrl-b를 누른 뒤 d로 분리합니다. 재접속 후 세션 목록을 확인하고 올바른 세션을 다시 연결하세요. 프로그램이 끝났는데도 셸이 계속 보일 수 있으니, 로그와 저장된 코드를 확인하세요. 이전 터미널이 사라졌다고 해서 즉시 두 번째 복사본을 시작하지 마세요.
tmux new -s campagne-amkdir -p runs
mkdir runs/campagne-a && (
code_retour=0
python -u traitement.py --config config.toml --output runs/campagne-a \
> runs/campagne-a/execution.log 2>&1 || code_retour=$?
printf '%s\n' "$code_retour" > runs/campagne-a/exit-code.txt
exit "$code_retour"
)tmux ls
tmux attach -t campagne-a4. 단순한 활동이 아닌 수락된 작업을 세기
Python의 -u 옵션은 표준 출력과 표준 오류의 버퍼링을 제거합니다. 이는 출력되는 메시지를 확인하는 데 도움이 되지만, 애플리케이션에 진행 이벤트를 생성하지는 않습니다. 라이브러리나 조용한 단계는 여전히 별도의 관찰이 필요할 수 있습니다.
이해할 수 있는 단계를 정의하세요: 읽기, 준비, 계산, 쓰기, 검증. 단위가 일정한 카운터를 추가하고, 알려진 경우 총계도 함께 추가하세요. 수락된 파티션을 세고 있다면, 로그 중간에 이름을 바꾸지 않고 읽은 행 수 카운터로 전환하지 마세요.
다음 교육용 예시는 500개 요소로 이루어진 8개 파티션, 즉 4000개 요소를 다룹니다. 그림에 나온 시점에서는 5개 파티션만 허용됩니다. 여섯 번째는 부분적이므로 합계에 포함되어서는 안 됩니다. 이 숫자들은 집계 규칙을 보여줄 뿐, 실제 Kernodeck 실행을 설명하지 않습니다.
표의 모든 열을 보려면 스크롤하세요.| 파티션 | 상태 | 수락된 것으로 집계된 요소 | 결정 |
|---|---|---|---|
| 1~5 | 검증됨 | 2 500 | 해당 ID와 결과를 유지합니다. |
| 6 | 부분적 쓰기 | 0 | 이 파티션을 완료된 것으로 알리지 마세요. |
| 7 및 8 | 처리 대기 | 0 | 작업 목록에 남겨 두세요. |
| 전체 | 불완전 | 4,000 중 2,500 | 최종 폴더를 수락하지 마세요. |
5. 중복 없이 침묵이나 중단을 살펴보기
카운터가 전혀 움직이지 않을 때는 마지막으로 알려진 단계와 마지막으로 완료된 단위를 식별하세요. 프로세스가 존재하는지, 오류 메시지가 나타났는지, 대상이 여전히 사용 가능한지 확인하세요. 모델의 느린 시작과 멈춘 루프는 동일한 정지 화면을 만들어낼 수 있으므로, 다음 점검은 상황에 따라 결정됩니다.
애플리케이션에서 자발적 종료를 준비하세요: 종료 요청, 안전한 단위 종료, 상태 저장, 그런 다음 종료. 신호와 인터럽트는 시스템에 따라 다릅니다. Python은 SIGKILL을 가로챌 수 없으며, Python 핸들러는 긴 네이티브 호출이 끝날 때까지 기다린 후에 실행될 수 있습니다. 따라서 종료 시 백업은 주기적 백업을 대체하지 않습니다.
연결이 끊긴 후에는 먼저 기존 세션과 실행을 다시 찾으세요. 종료가 확인된 후에는 무엇이 완전하고 무엇이 부분적인지 판단하세요. 훈련의 경우 재개하려면 모델과 최적화의 상세 상태가 필요하며, 전용 가이드는 이 경우를 새 프로세스에서 검증합니다.
6. 계약이 허용하는 것만 재개하기
이 예시에서 파티션 재개는 각 파티션이 독립적이고 입력, 코드, 구성이 동일하게 유지된다고 가정합니다. 이 경우 검증된 다섯 개의 결과를 보존하고, 여섯 번째를 완전히 다시 계산한 뒤 나머지 두 개를 이어서 처리할 수 있습니다. 이러한 가정이 성립하지 않으면 이 지름길은 정당화되지 않습니다.
새로운 줄을 부분 파일에 그냥 추가하지 마세요. 중복이 생기거나 두 가지 구성이 섞일 위험이 있습니다. 완전, 불완전, 부재를 구분하려면 예상되는 식별자를 사용하세요. 이전 상태는 설명 자료로 보존하고, 새로운 시도에는 별도의 대상을 지정하세요.
대규모 처리를 이 전략에 의존하기 전에, 통제된 중단 상황에서 전략을 검증하세요. 기준은 진행 메시지의 동일성이 아니라 계약에 따른 유효 출력의 동등성입니다. 학습, 외부 효과가 있는 연산, 분산 처리는 이 독립 파티션 예시와는 다른 보장을 요구합니다.
7. 작업을 마치기 전에 결과를 수락하고 회수하기
먼저 반환 코드를 확인한 다음, 출력을 입력 매니페스트와 대조하세요. 이 예시에서는 예정된 여덟 개의 파티션과 사천 개의 식별자를 누락이나 중복 없이 기다려야 합니다. 형식, 차원, 관련 값을 점검하세요. 파일을 읽는 것만으로는 올바른 결과가 들어 있다는 것이 증명되지 않습니다.
수락된 출력, 승인된 구성, 버전, 검증 보고서를 회수하세요. 원본과 복사본 간의 크기를 비교하고 필요하면 지문도 비교하세요. 동일한 지문은 바이트 전송을 확인하는 데 도움이 되지만, 모델의 품질이나 파일의 정당한 출처를 증명하지는 않습니다.
마지막으로 보존 대상에서 결과를 열어, 그것을 사용할 도구로 확인하세요. 컴퓨팅 접근이 끝나기 전에 이 단계를 준비하세요. 작업은 마지막 퍼센트가 백에 도달했을 때가 아니라, 검증된 결과를 회수하고 해석할 수 있을 때 완료됩니다.