연구실 사고뭉치 ep1. 서버를 다운시키다

큰 모델과 큰 사이즈의 데이터를 다루면서 가장 어려운 일은, 이걸 내 손 안에서 쥐락펴락 컨트롤 하는 일이다. 사실 연구실 인턴 생활을 하기 전까지는, 원격 서버를 어렴풋이만 사용해봤지 제대로 사용해보는 것은 연구실 일 하는 것이 처음이었다. 벌써 3개월째 생활을 하고있는데, 달에 한 번은 내가 꼭 서버 사고를 일으키고 있다. 이번 달은 무난히 넘어가는가 했더니, 어제 오늘 또 사고를 쳐버렸다.

 

발생한 현상.

데이터로더 코드 실행 중 (__iter__ 단계에서 추정) 갑작스러운 서버 끊김, 재접속 불가
(직접적으로 터미널에 OOM 에러 메세지가 뜬 것은 아니나, 나중에 서버 에러 로그를 보니 OOM 타입의 에러라고 한다.)

 

    def __iter__(self):
        random.seed(self.seed)
        # Create an iterator for each dataset 
        iterators = [itertools.islice(iter(dataset), num_samples) for dataset, num_samples in zip(self.datasets, self.samples_per_dataset)]

        # Chain(Combine) iterators into a single
        combined_iterator = itertools.chain(*iterators)
        combined_samples = list(combined_iterator)
        random.shuffle(combined_samples)
        
        return iter(combined_samples)

지피티 4o 선생님의 분석

 

원인은, Iterable Dataset 을 상속받은 Dataloader 코드를 구현하는 과정에서 len, shuffle 등의 메소드를 아무 생각없이 빈번히 사용한 것이 문제인 듯 하였다. 해당 메소드들은 전체 데이터셋 사이즈를 파악한 후, 사용자가 원하는 동작을 수행한다. 고로, 메모리 위에 모든 데이터셋을 띄워둬야하는 것이다. 데이터셋 사이즈를 100 샘플 이렇게 적게 잡아뒀을 때는 코드가 아무 문제없이 수행됐는데, 정 사이즈인 910K 샘플을 잡고 돌리다가 이런 사태가 발생하였다.

 

교훈.

1. 앞으로는 코드 구현할 때, 뇌 빼고 지피티에 의존하여 짜는 것이 아니라 꼭 시간복잡도, 공간복잡도 측면에서도 고려하여 구현한다.
2. 아이카 서버는 CPU 코어 수가 많지 않으니, 너무 과중한 작업은 돌리지 않는다.
3. OOM 에러는 소리소문없이 발생할 수도 있다. 

 

 

이번 사태는 교수님이 직접 인스턴스를 리부팅해주셔야했어서, 주말 아침부터 느닷없이 교수님을 호출하는 실례를 범해버렸다.

 

그리고 이렇게 또 사고를 친 내 모습에 실망스러웠다. 이런 사고들을 겪을 때마다, 내가 특히 실력이 없어서 그런건지, 혹은 누가와도 다 겪었을 시행착오인지 모르겠다고 생각한다. 그래서 왠지모르게 슬픈 하루였다.