반복할 때 또는 반복을 시작하기 전에 메모리 사용량이 증가하는 것이 보입니까?

@SsnL 반복 중에만.

#13243을 수정할 때 이것도 수정되었는지 확인해야 합니다.

num_workers>0 batch_sampler 를 사용할 때 OOM이 트리거될 때까지 메모리 사용량이 지속적으로 증가하는 비슷한 상황을 경험했습니다.

재현하기 위해

import math

from torch.utils.data import DataLoader


class Sampler:
    def __init__(self, n=100000, batch_size=32):
        self.n = n
        self.batch_size = batch_size

    def __len__(self):
        return math.ceil(float(self.n)/self.batch_size)

    def __iter__(self):
        batch = []
        for i in range(self.n):
            batch.append(i)
            if len(batch) == self.batch_size:
                yield batch
                batch = []
        if batch:
            yield batch


N = 100000000
train_data = list(range(N))


def ok():
    train_sampler = Sampler(len(train_data))
    train_loader = DataLoader(train_data,
                              num_workers=0,
                              batch_sampler=train_sampler)

    for i, item in enumerate(train_loader):
        if i % 10000 == 0:
            print(i)


def leaky():
    train_sampler = Sampler(len(train_data))
    train_loader = DataLoader(train_data,
                              num_workers=8,
                              batch_sampler=train_sampler)

    for i, item in enumerate(train_loader):
        if i % 10000 == 0:
            print(i)


print('Starting ok')
ok()
print('ok done, starting leaky()')
leaky()
print('leaky done')

환경

$ python3 collect_env.py
Collecting environment information...
PyTorch version: 0.4.0
Is debug build: No
CUDA used to build PyTorch: 9.1.85

OS: Ubuntu 16.04.5 LTS
GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
CMake version: version 3.5.1

Python version: 3.5
Is CUDA available: Yes
CUDA runtime version: 9.1.85
GPU models and configuration: GPU 0: GeForce GTX 1050 Ti with Max-Q Design
Nvidia driver version: 390.77
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.1.2
/usr/lib/x86_64-linux-gnu/libcudnn_static_v7.a

Versions of relevant libraries:
[pip] Could not collect
[conda] Could not collect

@ezyang

#13243을 수정할 때 이것도 수정되었는지 확인해야 합니다.

이 문제는 1.0.0.dev20181105 에 여전히 존재하며, 여기서 #13243이 수정되었습니다.

좀 더 조사한 후에 누출이 발생하는 정확한 시나리오를 찾았습니다. 아래 코드 예제를 고려하십시오.

from torch.utils.data import Dataset, DataLoader
import numpy as np
import torch


class DataIter(Dataset):
    def __init__(self):
        self.data_np = np.array([x for x in range(24000000)])
        self.data = [x for x in range(24000000)]

    def __len__(self):
        return len(self.data)

    def __getitem__(self, idx):
        data = self.data[idx]
        data = np.array([data], dtype=np.int64)
        return torch.tensor(data)


train_data = DataIter()
train_loader = DataLoader(train_data, batch_size=300,
                          shuffle=True,
                          drop_last=True,
                          pin_memory=False,
                          num_workers=18)

for i, item in enumerate(train_loader):
    if i % 1000 == 0:
        print(i)

Python의 표준 정수 목록인 self.data 변수를 사용하면 데이터 누수가 발생합니다. 그러나 self.data_np 변수를 사용하면 동일한 데이터를 가지고 있지만 Numpy 배열 형태로 되어 있으면 누수가 발생하지 않습니다.
또 다른 관찰은 DataLoader 의 shuffle=False 인 경우 누출이 훨씬 덜 심각하다는 것입니다.

비슷한 문제에 직면했지만 제 경우에는 numpy 배열에서도 발생합니다. 저는 Python 3.7 및 PyTorch 야간 릴리스를 사용하고 있습니다.

멀티프로세싱이 pytorch의 후드 아래에서 실제로 어떻게 작동하는지 모르지만 우리는 fast.ai 포럼(https://forums.txt)에서 이 "메모리 누수" 문제(아마도 메모리 누수가 아닐 수도 있습니다!)에 대해 광범위하게 논의했습니다. fast.ai/t/runtimeerror-dataloader-worker-is-killed-by-signal/31277/55?u=marcmuc). 여기에 약간의 통찰력을 추가할 수 있는 예비 결과(이것이 적용되지 않는 경우 의견을 말하십시오!):

Python Multiprocessing: Python 의 공유 메모리에 임의의 Python 개체(단순한 목록 포함)를 저장할 수 있는 방법은 없습니다. refcounts는 메모리 페이지 단위로 추가되므로 소비가 천천히 증가합니다. 프로세스(작업자)는 결국 모든/대부분의 메모리를 비트 단위로 복사하게 되므로 메모리 오버플로 문제가 발생합니다. 이 동작에 대한 가장 좋은 설명은 여기 (SO)입니다.

가능한 해결책:
지금처럼 멀티프로세싱 사용하기: 파이썬 멀티프로세싱이 이러한 refcount 효과 없이 작동하려면 프로세스 풀이 생성되고 작업자가 분기되기 전에 객체가 "호환"되고 multiprocessing.Array 로 래핑되어야 합니다. 이것은 메모리가 실제로 공유되고 기록 중 복사가 발생하지 않음을 보장합니다. 이것은 numpy 배열에 대해 수행하는 방법을 설명하고 그 이유를 다시 설명합니다. copy-on-write가 이 모든 것을 불필요하게 만든다는 이 좋은 답변의 작성자라도 일부 잘못된 진술에 혼동하지 마십시오. 이는 사실이 아닙니다. 한 의견은 또한 다음과 같이 지적합니다.

"참고로 Python에서 fork()는 실제로 액세스 시 복사를 의미합니다(객체에 액세스하는 것만으로도 참조 횟수가 변경되기 때문입니다)."

나는 pytorch 사용을 이해하는 torch.multiprocessing 드롭인 교체에 익숙하지 않지만 핵심 python refcount 문제를 제거할 수 없을 것이라고 가정합니다.

@mprostock torch.multiprocessing은 사용자 지정 피클러가 있는 단순히 Python 다중 처리입니다. 커스텀 피클러는 torch.tensor 를 만날 때마다 자동으로 공유 메모리로 이동하므로 적어도 torch.tensor 객체에서는 copy-on-write가 발생하지 않습니다.

설명 감사합니다! 나는 @bfreskura 의 재생산 예제를 실험했고 이제 문제를 정확히 지적할 수 있다고 생각합니다.

위의 bfreskura의 재생산 예제는 일반 파이썬 목록과 numpy 배열의 차이점을 보여주었습니다. 그러나 문제는 파이썬 목록 자체에만 있는 것이 아니라 객체 유형의 numpy 배열에서도 동일하게 발생합니다. Python 목록은 객체에 대한 참조만 저장하고 객체는 메모리에 별도로 보관됩니다. 모든 객체에는 refcount가 있으므로 목록의 모든 항목에는 refcount가 있습니다.

Numpy 배열(표준 np 유형)은 메모리에 연속 블록으로 저장되며 하나의 참조 카운트가 있는 하나의 객체일 뿐입니다.

이것은 numpy 배열을 객체 유형으로 명시적으로 만들면 변경되어 일반 파이썬 목록처럼 동작하기 시작합니다((문자열) 객체에 대한 참조만 저장). 메모리 소비와 동일한 "문제"가 이제 나타납니다.

이것은 일반 목록(또는 객체 유형의 numpy 배열)에서 "메모리 누수"를 보는 이유를 설명합니다. 이는 실제로 메모리 누수가 아니라 참조 카운트 변경으로 인한 분기된 파이썬 프로세스의 액세스 시 복사 문제입니다.

따라서 문제는 아마도 (종종) 텐서 또는 실제 토치 개체와 아무 관련이 없으며, 오히려 데이터 로더/데이터 세트 내에서 일반적으로 사용되는 파일 이름 및 레이블 사전 목록과 관련이 있습니다.

누군가가 빨리 그것을 시도하고 싶다면 나는 노트북 요지 를 만들었습니다.
메모리 소비를 살펴보십시오(전체 시스템의 빠르고 더티한 메모리이므로 다른 프로세스의 작은 영향으로 시스템을 깨끗하게 유지하려고 했습니다)

고정 길이 문자열 배열의 메모리 소비(GB):

개체 배열의 메모리 소비(GB)(변경만 가능)

나는 같은 문제에 직면하고 있습니다. num_workers > 0이면 RAM을 매우 빠르게 채웁니다.
내 코드에서 더 이상 필요하지 않다고 생각되는 변수를 삭제하고 모든 반복에서 gc.collect()를 호출하지만 아무 것도 도움이 되지 않습니다.
해결 방법이 있습니까?

dict에서 pandas로, 목록에서 numpy 배열로 전환하면 도움이 됩니다.

나는 같은 문제에 직면하고 있습니다. num_workers > 0이면 RAM을 매우 빠르게 채웁니다.
내 코드에서 더 이상 필요하지 않다고 생각되는 변수를 삭제하고 모든 반복에서 gc.collect()를 호출하지만 아무 것도 도움이 되지 않습니다.
해결 방법이 있습니까?

답장을 보내 주셔서 감사합니다. 나는 그것을 시도하고 희망적으로 작동합니다.

이 문제에 대한 해결책을 요청할 수 있습니까? 마지막으로 매일 빌드된 pytorch에서 @samgd 코드를 시도했지만 여전히 누출되고 있었습니다.

@Godricly 위의 @mprostock 및 @soumith 의 의견을 참조하십시오. 이것은 실제로 누출이 아니지만 python 기본 목록을 사용하는 불행한 동작입니다. 토치 텐서 또는 np 어레이를 사용하면 이 메모리 문제를 해결할 수 있습니다.

@mprostock 다른 것이 아니라 액세스 시 복사로 인해 메모리를 사용하여 생성된 복사본을 의미합니까? 그리고 사용 후에는 복사가 해제되지 않습니까?

누군가는 최소한 이미지 데이터 세트에 대한 적절한 증강 작업을 작성하고 단계를 높여야 합니다. 이러한 모든 다중 처리 속임수에 대한 모든 이유는 비전 데이터 세트가 다중 코어에서 이미지를 디코딩하고 자르기 _가져 있기 때문입니다. 디코딩 및 기하학적 이미지 변환(크기 조정, 자르기 뒤집기, 전단, 아핀)을 처리하고 배치 텐서를 직접 생성하는 작업이 있다면 다중 처리를 전혀 사용할 필요가 없으며 더 나아가 비기하학적 증강 단계를 사용할 필요가 없습니다. (색상, 미백/정규화, 노이즈)는 내부 연산 병렬 처리를 사용하여 전체 텐서를 찢을 수 있습니다. 주석(경계 상자, 마스크, 키포인트 등)의 병렬 변환을 가능하게 하기 위해 텐서의 각 샘플에 대한 변환 매개변수를 외부에 노출하도록 이러한 연산을 설계할 때 주의를 기울여야 합니다.
또는 더 나은 방법은 이 서버를 여러 프로세스(및 다른 DL 프레임워크)에서 사용할 수 있도록 하는 것입니다.

@mprostock 훌륭한 설명 감사합니다!

그러나 아직 해결책이 제시되지 않았습니다. Dataset 객체에 파일 이름 목록을 저장하는 것이 공정해 보이지만 어떻게 사용할 수 있습니까? 누구든지 그것을 알아 냈습니까?

@1e100 @fmassa 가 torchvision 에 네이티브 이미지 확대 작업을 추가하는 작업을 하고 있다고 생각합니다. 이는 이 문제를 해결하는 데 도움이 될 것입니다.

이 문제에 대한 업데이트가 있습니까?

많은 공유 메모리를 사용하면 문제가 해결되었습니다. 다음은 도커 컨테이너 내부에서 코드를 실행하고 있고 그렇지 않으면 공유 메모리를 설정할 수 없는 경우 스크립트 내부에서 공유 메모리를 설정하는 해킹입니다.

os.system(f"mount -o remount,size={args.shared_memory_size} /dev/shm")

공유 메모리 크기는 예를 들어 총 RAM의 절반이 될 수 있습니다. 예를 들어 biiig 머신의 경우 '80G'입니다.

메모리가 특정 지점까지 _여전히_ 크립지만 허용되는 파일 설명자 수를 변경하여 이 문제와 관련된 unable to open shared memory object </torch_22291_1137042840> in read-write mode 오류 발생에 대한 해결 방법을 찾았습니다.

허용된 파일 설명자 수를 확인하려면 bash에 ulimit -a 를 입력하면 -n 태그 아래에 표시됩니다. 현재 셸에 대한 이 제한을 높이려면(즉, 서버에 대한 권한이 없는 경우) 다음을 실행합니다.
배쉬: ulimit -n NEW_VALUE

전체 시스템에 대해 변경하려면 여기를 참조 하십시오 .

따라서 내가 올바르게 이해한다면 작업자 프로세스는 목록에 액세스할 때마다 긴 파일 경로 목록의 복사본을 생성합니까? 그러나 이 임시 복사본은 해당 프로세스에 대한 __getitem__ 함수가 반환되자마자 범위를 벗어나(결과적으로 파괴됨) 되지 않습니까? RAM 소비가 제한 없이 증가하는 이유는 무엇입니까?

누군가가 이 문제를 피하는 방법에 대한 몇 가지 모범 사례가 포함된 짧은 가이드를 만들었다면 좋을 것입니다. 숫자 값을 사용하면 Python 목록을 NumPy 배열로 쉽게 교체할 수 있지만 (가변 크기) 문자열 문제를 완화하는 방법이 명확하지 않습니다.

제 경우에는 생성자에서 생성/채워진 사용자 정의 클래스 개체 목록이 있습니다. 기본적으로 파일 경로 세트만 포함합니다. 그런 다음 __getitem__ 내부에서 해당 이미지를 로드하고, 일부 전처리를 수행하고, 토치 텐서로 변환한 다음 반환하기 전에 로드된 이미지에서 명시적으로 del 를 계산합니다. 문제는 겉보기에 무해해 보이는 전처리 단계를 추가하면 이러한 한계를 벗어난 메모리 사용 문제가 발생한다는 것입니다.

Py 3.8의 mp.shared_memory 는 많은 비텐서/nparray 객체를 공유하는 데 충분한 해결 방법을 제공할 수 있습니다(예: 공유 목록: https://docs.python.org/3.8/library/multiprocessing.shared_memory.html). #multiprocessing.shared_memory.ShareableList. :)

면책 조항 : 나는 실제로 문서를 자세히 읽지 않았습니다.

여기서 우리가 할 수 있는 조치가 있습니까? 일부 사용 사례를 해당 사례로 옮기는 것을 문서화하기 위해 토치비전에서 지원되는 충분한 이미지 변환이 있습니까?

여기에서 요점을 명확히 하기 위해: @1e100 이 제안한 것을 구현하는 것은 우리가 torchvision의 로드맵에 포함하고 있는 것이지만, 우리 목록의 맨 위에 있지 않으며 아마도 먼저 중첩 텐서 지원이 필요할 것입니다.

즉, 이것은 이 문제에 대한 일반적인 수정이 아닙니다. 다른 접근 방식(예: GPU의 변환)을 사용하여 데이터 로드에서 다중 처리의 필요성을 우회할 뿐입니다.

누군가가 중첩 텐서를 언급하는 것을 보았을 때 cc @cpuhrsch . (그런데 @cpuhrsch , 중첩 텐서에 대한 모듈 레이블을 만들고 https://github.com/pytorch/pytorch/issues/24422 에서 추가할 수 있습니까?)

이 버그가 1년 동안 해결되지 않은 이유는 무엇입니까?

@IMLHF 이 문제 설명의 첫 번째 줄 또는 위의 논의를 참조하십시오. 이것은 실제로 누출이 아니라 우리의 손을 벗어난 불행한 파이썬 디자인이기 때문입니다. pytorch와 numpy는 모두 텐서 및 ndarray에 대한 사용자 지정 직렬화를 구현하여 이 문제를 해결하려고 했습니다. 그러나 우리는 일반적인 데이터 구조를 설명할 수 없습니다. 이것은 사용자가 이 문제를 해결할 수 있도록 더 많은 유틸리티를 구현하고 있기 때문에 열려 있습니다.

각 반복 끝에 torch.cuda.empty_cache() 를 추가하면 이 문제를 해결하는 데 도움이 됩니다. 이것을 추가한 후 메모리 사용량이 누적되지 않고 변동합니다.

아마도 우리는 경고를 추가해야 합니다.

@VitalyFedyunin 이것을 볼 대역폭이 있습니까? 최소한 이것이 https://github.com/pytorch/pytorch/issues/17499와 동일한 문제인지 알아낼 수 있습니까?

내 프로젝트에서 텐서를 사용하는 대신 ndarray를 사용하여 이 문제를 해결한다고 생각합니다.

내 이전 코드는

def df2var(x):
    return (torch.LongTensor(token2id(x['Query'], max_char = max_length_char)), 
            torch.tensor(coll2id[x['Agg_Coll']], dtype = torch.long))

class Making_Dataset(Dataset):
    def __init__(self, input_dataframe):
        self.dataset = input_dataframe.apply(lambda x : df2var(x), axis = 1)

    def __len__(self):
        return len(self.dataset)

    def __getitem__(self, data_index):
        return self.dataset[data_index]

그리고 다음과 같이 코드를 수정했습니다.

class Making_Dataset(Dataset):
    def __init__(self, input_dataframe):
        self.text = np.array([token2id(q, max_char = max_length_char) for q in input_dataframe.Query])
        self.labels = np.array([coll2id[coll] for coll in input_dataframe.Agg_Coll])

    def __len__(self):
        return len(self.text)

    def __getitem__(self, data_index):
        return self.text[data_index], self.labels[data_index]

코드를 수정한 후 각 에포크의 메모리 증가 문제가 내 프로젝트에서 사라졌습니다.
이 문제의 원인이 무엇인지 정확히 모르기 때문에 이에 대한 모든 의견을 환영합니다!

Ubuntu 18.04의 CUDA 10이 포함된 Torch 1.3.0과 유사한 문제가 있습니다. 이것은 64GB RAM이 있는 AWS 시스템에서는 문제가 되지 않았지만 128GB RAM 및 128GB 스왑이 있는 로컬 시스템에서는 150 에포크도 통과할 수 없습니다. 메모리 사용량이 몇 GB(예상)에서 128GB로 계속 조금씩 늘어납니다 + GB.

업데이트

내 문제는 교활한 작은 버그였습니다. 교육 통계를 기록하는 동안 순수 값과 함께 기울기 정보를 저장하고 있었습니다. 이 정보는 불필요하고 각 에포크의 메모리 공간에 추가됩니다.

Py 3.8의 mp.shared_memory는 많은 비텐서/nparray 객체(예: 공유 목록)를 공유하는 데 충분한 해결 방법을 제공할 수 있습니다.
https://github.com/pytorch/pytorch/issues/13246#issuecomment -513480017

많은 공유 메모리를 사용하여 문제가 해결되었습니다.
https://github.com/pytorch/pytorch/issues/13246#issuecomment -487042977

안녕하세요, 이 주제에 대해 조금 늦었지만 사전과 동일한 문제에 직면해 있습니다.
이 해킹으로 성공한 사람이 있습니까?

이것은 여전히 ​​유효한 문제입니다. 누군가가 메모리 누수를 일으키지 않고 DataLoaders에서 여러 작업자를 사용하는 방법에 대한 모범 사례 목록을 제공할 수 있습니까?

@marrrcin 내 생각에 가장 좋은 방법은 텐서를 비싼 것으로 간주하는 것이므로, 특히 텐서에 그라디언트 정보가 있을 가능성이 있는 경우 사용 빈도에 주의해야 합니다.

예를 들어 torch 작업을 수행해야 할 때까지 모든 항목을 목록 또는 numpy.ndarray 로 저장하는 것이 좋습니다.

@AudreyBard님 답변 감사합니다. 내 데이터 세트 코드에는 모든 것이 numpy/lists/strings/int로 저장되어 있으며 텐서를 사용하는 유일한 부분은 __getitem__ 이고 나중에 collate_fn (패딩 적용)입니다. requires_grad 가 false로 설정된 텐서를 생성해야 합니까? 내 코드가 num_workers>0으로 들어가면 메모리 누수가 시작됩니다.

모바일이라 형식이 안맞아서 죄송합니다.

@marrrcin 나는 일반적으로 __getitem__ 의 tensor 로 입력 데이터(이미지 또는 신호 등)만 캐스트합니다. 내 레이블 등은 일반적으로 목록으로 반환됩니다. 어떤 종류의 데이터를 사용하고 있는지 또는 특별한 종류의 패딩을 사용하고 있는지 잘 모르겠지만 일반적으로 __getitem__ torchvision.transforms #$ 를 사용합니다. 그만한 가치가 있기 때문에 사용자 정의 collate_fn 를 구현하는 경우는 거의 없습니다.

생각: 나는 메모리 누수라고 생각했던 것을 경험하고 있었기 때문에 원래 여기에 게시했습니다. 매 에포크마다 불필요한 데이터에 매달리고 있었고, 제 입장에서는 정말 미묘한 변수 관리였을 때 누수 증상이 나타났습니다. 무슨 일이 일어나고 있는지 정확히 파악하는 데 시간이 걸렸습니다.

@AudreyBeard 제 경우는 이미지/torchvision과 관련이 없습니다. 가변 길이 텍스트에서 추출한 토큰에 패딩을 사용했기 때문에 collate_fn 사용해야 합니다.

class PaddingCollateFn:
    def __call__(self, batch):
        sorted_batch = sorted(batch, key=lambda x: x[0].shape[0], reverse=True)
        sequences = [x[0] for x in sorted_batch]
        sequences_padded = torch.nn.utils.rnn.pad_sequence(sequences, batch_first=True)

        attention_masks = [torch.tensor([1 for _ in x[0]]) for x in sorted_batch]

        attention_masks_padded = torch.nn.utils.rnn.pad_sequence(
            attention_masks, batch_first=True
        )
        lengths = torch.tensor([len(x) for x in sequences])
        labels = torch.tensor([x[1] for x in sorted_batch])

        return (sequences_padded, lengths, attention_masks_padded), labels

패딩 후 원본 텐서를 삭제해야 하나요(예 del 사용)? collate_fn 가 완료되면 해당 항목에 대한 참조가 없으므로 범위를 벗어나 제거될 것이라고 생각했습니다.

나는 이것을 Pytorch 버전 1.3.1에서 만났습니다.... ImageNet을 훈련할 때....누군가 아이디어가 있습니까?
제 경우에는 24개의 num_workers를 사용합니다. 일반적으로 Epoch 1에서는 약 110G 메모리가 필요하지만 두 번째 Epoch를 훈련할 때 메모리가 모두 소모되고 시스템이 데이터로더를 죽일 것입니다..... 왜인지 몰라....

나에게 문제는 이미 numpy 배열을 데이터 로더 __getitem__ 에서 토치 텐서로 변환하고 있다는 것입니다.

Numpy 배열은 모델로 전송되기 직전에 트레이너 루프에서 토치 텐서로만 변환되어야 합니다. 그렇지 않으면 텐서가 공유 메모리를 범위를 벗어나게 만듭니다.

watch -n .3 df -h 명령을 실행하여 공유 메모리를 모니터링할 수 있습니다.
공유 메모리는 /dev/shm 행에 해당합니다.
사용된 양은 각 Epoch 후에 증가하지 않아야 합니다.

나는 같은 문제가있다

이 버그는 pytorch 1.4.0에서 해결되지 않았습니다.

나도 같은 문제가있다

저도 같은 문제에 직면해 있습니다.
1) 불필요한 변수를 모두 삭제
2) 목록 대신 numpy 배열 사용
3) gc.collect() 사용

@annukkaa 및 기타: 문자열 목록을 많은 개체로 저장하기 때문에 np.array(list_of_paths) 를 사용하는 것만으로는 충분하지 않습니다. np.array(list_of_paths).astype(np.string_) 를 사용하여 배열을 정사각형 바이트 배열로 캐스팅합니다(그리고 실제로 문자열을 사용할 때 바이트에서 str로 변환해야 함). 도움이 될 것입니다. 또한 공유 메모리를 높은 값(예: 100GB)으로 설정합니다.

이 스레드에서 명시적으로 언급된 것을 본 적이 없으므로 내 솔루션을 공유할 것이라고 생각했습니다.
제 경우에는 모든 반복에 액세스하여 빠르게 CPU 메모리를 고갈시킨 데이터 세트에 사용자 지정 클래스 개체와 문자열 목록이 있었습니다.
공유 상태를 처리하는 다중 처리 관리자 개체 를 사용하여 클래스와 목록을 래핑하여 메모리 누수를 제거할 수 있었습니다.

최소한의 예제와 연결하면 코드는 다음과 같을 것입니다.

from torch.utils.data import Dataset, DataLoader
import torch
from multiprocessing import Manager


class DataIter(Dataset):
    def __init__(self):
        manager = Manager()
        self.data = manager.list([x for x in range(24000000)])

    def __len__(self):
        return len(self.data)

    def __getitem__(self, idx):
        data = self.data[idx]
        return torch.tensor(data)


train_data = DataIter()
train_loader = DataLoader(train_data, batch_size=300,
                          shuffle=True,
                          drop_last=True,
                          pin_memory=False,
                          num_workers=18)

for i, item in enumerate(train_loader):
    if i % 1000 == 0:
        print(i)

객체가 피클되기 때문에 약간의 오버헤드가 있지만 메모리가 폭발하는 것보다 좋은 대안입니다.

이게 다 고쳐질까요????

문제가 아직 열려있는 것 같습니다.

ndarrays를 사용해도 도움이 되지 않습니다. 작업자가 0인 상태에서 CPU RAM을 약 4배 올립니다.
델을 시도했지만 유의미한 개선은 없었습니다.

안녕 모두,

나는 이것에 대한 해결책을 시도했고 이것은 절대적인 아름다움처럼 작동합니다.

나를 위해 로컬에 저장된 numpy 배열로 imagenet 데이터를 저장하고 있습니다.

내 사용자 정의 데이터 세트를 다음과 같이 작성했습니다 ---

`수입 토치
Torch.utils에서 데이터 가져오기
numpy를 np로 가져오기

클래스 DataSetBuilder(data.Dataset):
"""TinyImagenet 데이터 세트."""

def __init__(self, rootpath, train=True, transform=None):
    """
    Args:
        rootpath: Path to the pytorch file with annotations.
        root_dir (string): Directory with all the images.
        transform (callable, optional): Optional transform to be applied
            on a sample.
    """
    self.path = rootpath
    self.transform = transform
    self.train = train
    # Load input data
    if self.train:
        self.X_ = np.load(self.path +'x_train.npy')
    else:
        self.X_ = np.load(self.path +'x_test.npy')
    # Load target data
    if self.train:
        self.y_ = np.load(self.path +'y_train.npy')
    else:
        self.y_ = np.load(self.path +'y_test.npy')

def __len__(self):
    if self.train:
        dataFile = self.path + 'x_train.npy'
    else:
        dataFile = self.path + 'x_test.npy'

    data = np.load(dataFile)
    return data.shape[0]

def __getitem__(self, idx):
    if torch.is_tensor(idx):
        idx = idx.tolist()
    X = self.X_[idx, :, :, :]
    y = self.y_[idx]
    if self.transform is not None:
        X = self.transform(X)
    return X, torch.from_numpy(y).type(torch.LongTensor)`

__getitem__에 데이터를 로드하는 대신 객체를 빌드할 때 로드하고 있습니다. 즉, 매번 동일한 numpy 배열을 메모리에 로드하지 않고 객체 생성 시 한 번에 로드합니다.

도움이 되었기를 바랍니다!

이것이 효과가 있다면 댓글을 남겨주세요... :-)

안녕하세요 @varinder-singh님,
해결책을 찾으셨다니 다행입니다. 이전 에 @bfreskura 가 제공한 numpy 예제와 이것이 어떻게 다른지 모르겠습니다. 귀하의 __getitem__ 는 또한 numpy 배열에서 데이터를 슬라이스합니다.
코드를 잘못 읽고 있는 것 같습니다. 메모리 소비에 다른 영향을 미치는 이유를 설명해 주시겠습니까?

현재 프로젝트에서 이 문제가 발생하고 이 스레드를 읽은 후 내 생각을 추가하고 다소 다양한 솔루션을 제공하는 것이 유용할 수 있다고 생각합니다.

먼저 첫 번째 것들:

1) 여기에서 관찰할 수 있는 모든 것을 고려하면 @mprostock 의 진단이 정확합니다. 당신의 작업 덕분에 혼자서 땅을 파는데 많은 시간을 절약할 수 있었습니다.
2) 물론 @sumith 의 응답도 정확하지만 @mprostock 의 이후 객체 배열 게시물에서 언급한 이유로 인해 이 경우에는 적용되지 않습니다.

이것은 pyTorch 문제가 아닙니다. 이것은 파이썬 문제이므로 거기에서 해결해야 합니다. 그러나 문제는 Python의 메모리 관리의 필수적인 부분인 참조 카운팅으로 인해 발생하기 때문에 이는 곧 발생하지 않을 수 있습니다. 위에서 제안한 해결 방법 중 일부는 흥미롭지 만 왜 그러한 길이로 이동합니까? 작업이 파일 이름과 같은 여러 가변 길이 시퀀스에 공동으로 액세스하는 것이라고 가정하면 새로운 것을 발명할 필요가 없습니다. numpy를 사용하여 시퀀스를 압축하고 간접 조회를 수행하기만 하면 됩니다. 내 말을 이해하려면 이 스레드에서 논의된 문제를 완전히 피하는 아래 코드를 참조하십시오.

@mprostock 및 @smolendawid 문자열은 본질적으로 정수 시퀀스이며 numpy에서 쉽게 처리할 수 있는 유형입니다. 아래 예제는 여러 데이터 로더 간에 문자열 목록(예: 이미지의 파일 이름)을 공유하도록 조정되었습니다.
@marrrcin 모범 사례를 요청하셨습니다. 이것은 강력하며 가변 길이 시퀀스의 모든 목록에서 작동합니다. 현재 프로젝트에서 각 차원의 길이가 가변적인 다차원 데이터에 대해 이것의 약간 더 정교한 변형을 사용합니다.
@SsnL 이것은 멋진 Python 3.8 구성을 사용하지 않고 /issues/ 20433 에서 @zhiweifang과 논의한 문제를 암시적으로 해결합니다.

import numpy as np
import torch
from typing import Union

# --- UTILITY FUNCTIONS ---
def string_to_sequence(s: str, dtype=np.int32) -> np.ndarray:
    return np.array([ord(c) for c in s], dtype=dtype)

def sequence_to_string(seq: np.ndarray) -> str:
    return ''.join([chr(c) for c in seq])

def pack_sequences(seqs: Union[np.ndarray, list]) -> (np.ndarray, np.ndarray):
    values = np.concatenate(seqs, axis=0)
    offsets = np.cumsum([len(s) for s in seqs])
    return values, offsets

def unpack_sequence(values: np.ndarray, offsets: np.ndarray, index: int) -> np.ndarray:
    off1 = offsets[index]
    if index > 0:
        off0 = offsets[index - 1]
    elif index == 0:
        off0 = 0
    else:
        raise ValueError(index)
    return values[off0:off1]


# --- OUR DATASET CODE STARTS HERE ---
class MyDataset(torch.utils.data.Dataset):

    def __init__(self):
        strings = [
            'I like', # You can use np.int8 for ASCII strings.
            'chocolate',
            '我喜欢', # If you use anything that is not standard ASCII,
            '巧克力', # need to use np.int16, or even np.int32.
        ]

        # Convert each string to sequence of codepoints (integer),
        # and then pack them into a numpy array.
        seqs = [string_to_sequence(s) for s in strings]
        self.strings_v, self.strings_o = pack_sequences(seqs)

    def __len__(self): return 4

    def __getitem__(self, i):
        # Use indirect lookup to fetch the i-th sequence. This only uses integer numpy
        # array lookups, which avoids that the objects are subsequently replicated by
        # child processes.
        seq = unpack_sequence(self.strings_v, self.strings_o, i)
        string = sequence_to_string(seq)
        # ACTION NEEDED: You probably do not want to return the string itself ;-).
        return string


m = MyDataset()
for i in range(len(m)):
    print(i, '=', m[i])

# Output
# -------
# 0 = I like
# 1 = chocolate
# 2 = 我喜欢
# 3 = 巧克力

나는 이 문제를 해결할 수 있었고 내 2센트를 공유하고 싶습니다. 나는 기본적으로 문자열이 문제라고 @harpone 과 다른 사람들이 지적한 아이디어를 따랐습니다. 내 Dataset 클래스에 2개의 문제가 있는 인수가 있습니다.

1. numpy 문자열 배열(.astype(str)을 사용한 캐스팅은 도움이 되지 않았습니다)
2. 문자열에서 numpy 벡터로의 사전

메모리 누수를 막으려면 1과 2를 모두 수정해야 했습니다. 1의 경우 내 문자열은 실제로 사전의 numpy 벡터에 액세스하기 위한 해시이므로 고정 크기 사전이 있으므로 모든 문자열을 정수로 변환했습니다.

2의 경우 정수 키를 사용하도록 사전을 변환했지만 메모리 누수는 여전히 지속되었습니다. 실제로 작동한 것은 사전을 Dataset 클래스에 전혀 전달하지 않고 __getitem___에서 interger 키를 반환하고 Pytorch 텐서로 사전 인덱싱/이동/내 기차 루프에서 GPU로 승격하는 것이었습니다.

데이터 로더 프로세스가 매 에포크(epoch)마다 스스로를 다시 초기화하고 누출된 메모리를 모두 정리하도록 하는 방법이 있습니까?

@Pozimek 그들은 이미 모든 시대를 다시 초기화합니다.

그렇다면 지금 가장 좋은 방법은 무엇입니까?

@wangchust : @bashimao 가 제안한 솔루션은 적당히 큰(2,500만 개 이상의 텍스트 시퀀스) 데이터 세트에서도 아름답게 작동했습니다.

@wangchust : @bashimao 가 제안한 솔루션은 적당히 큰(2,500만 개 이상의 텍스트 시퀀스) 데이터 세트에서도 아름답게 작동했습니다.

저도 요. @bashimao 의 솔루션은 매우 잘 작동합니다.

안녕하세요 여러분, 다시 왔습니다. 데이터 로더 작업자가 주 프로세스에서 분기할 때 "OverflowError: 4GiB보다 큰 바이트열 개체를 직렬화할 수 없습니다"를 충족하는 사람이 있습니까?

안녕하세요 여러분, 다시 왔습니다. 데이터 로더 작업자가 주 프로세스에서 분기할 때 "OverflowError: 4GiB보다 큰 바이트열 개체를 직렬화할 수 없습니다"를 충족하는 사람이 있습니까?

@wangchust 직렬화 중이라면 아마도 뭔가 잘못하고 있을 것입니다. 각 프로세스는 4개 또는 아무리 큰 개체가 기가바이트 단위라도 역직렬화하고 직렬화된 개체를 재구성합니다. 따라서 메모리를 복제하고 병렬 프로세스가 많으면 결국 메모리가 부족해집니다. 이 스레드에서 나와 다른 사람들이 제안한 조치의 요점은 메모리 복제를 피하는 것입니다. 내 첫 번째 문장에서 말했듯이, 나는 당신이 아마도 꽤 기본적인 수준에서 뭔가 잘못했다고 믿습니다.

사용자 지정 텐서 지원 문자열 배열이 https://gist.github.com/vadimkantorov/86c3a46bf25bed3ad45d043ae86fff57 에 도움이 되는 것 같습니다.

import torch

class TensorBackedImmutableStringArray:
    def __init__(self, strings, encoding = 'utf-8'):
        encoded = [torch.ByteTensor(torch.ByteStorage.from_buffer(s.encode(encoding))) for s in strings]
        self.cumlen = torch.cat((torch.zeros(1, dtype = torch.int64), torch.as_tensor(list(map(len, encoded)), dtype = torch.int64).cumsum(dim = 0)))
        self.data = torch.cat(encoded)
        self.encoding = encoding

    def __getitem__(self, i):
        return bytes(self.data[self.cumlen[i] : self.cumlen[i + 1]]).decode(self.encoding)

    def __len__(self):
        return len(self.cumlen) - 1

    def __list__(self):
        return [self[i] for i in range(len(self))]

아마도 이와 같은 sth는 핵심 PyTorch에 포함할 가치가 있습니다.

누구든지 사전이 작동하고 누출되지 않도록 운이 있습니까?
위에서 이 게시물 을 보았지만 해당 의견에서 제안하는 것처럼 외부에서 작업을 수행하는 대신 작업자 내부의 일부 유형의 해시 테이블에 액세스하고 싶습니다.

다음 중 하나를 고려하고 있습니다.

• 다중 처리 관리자 dict
• 공유 메모리 또는 mmap
• pyobject가 없는 자체 개발한 numpy 기반 해시 테이블.

공유 메모리는 가장 유망하고 python 옵션에 고유한 것처럼 보입니다. dict를 사용하는 이유가 궁금합니다. 여기서 일반적인 패턴은 항목 목록(일반적으로 문자열)을 갖고 색인을 생성하는 것입니다.

나에게 그것은 원래 dicts 목록이었습니다 (예제 메타 데이터 목록, 모든 예는 dict였습니다)

알았어요. 일반적으로 dicts는 메모리 액세스 패턴이 순차적이지 않기 때문에 더 어렵게 만듭니다. Fork-safe 데이터 구조 지원을 추가할 생각입니다.

공유 메모리는 가장 유망하고 python 옵션에 고유한 것처럼 보입니다. dict를 사용하는 이유가 궁금합니다. 여기서 일반적인 패턴은 항목 목록(일반적으로 문자열)을 갖고 색인을 생성하는 것입니다.

@VitalyFedyunin 팁 주셔서 감사합니다. 공유 메모리를 먼저 시도해 볼 수 있습니다.
dict의 이유는 바로 지금 데이터 생성 단계에서 임의 샘플링 기능에 대한 요소의 O(1) 조회입니다. 보다 구체적으로, dict가 user_id에 대해 입력되고 값이 해당 사용자와 관련된 긍정적인 예의 목록인 "트리플렛 마이닝"입니다. 예를 보려면 여기 를 참조하십시오.

@marrrcin 나는 일반적으로 __getitem__ 의 tensor 로 입력 데이터(이미지 또는 신호 등)만 캐스트합니다. 내 레이블 등은 일반적으로 목록으로 반환됩니다. 어떤 종류의 데이터를 사용하고 있는지 또는 특별한 종류의 패딩을 사용하고 있는지 잘 모르겠지만 일반적으로 __getitem__ torchvision.transforms #$ 를 사용합니다. 그만한 가치가 있기 때문에 사용자 정의 collate_fn 를 구현하는 경우는 거의 없습니다.

생각: 나는 메모리 누수라고 생각했던 것을 경험하고 있었기 때문에 원래 여기에 게시했습니다. 매 에포크마다 불필요한 데이터에 매달리고 있었고, 제 입장에서는 정말 미묘한 변수 관리였을 때 누수 증상이 나타났습니다. 무슨 일이 일어나고 있는지 정확히 파악하는 데 시간이 걸렸습니다.

@AudreyBard 감사합니다. 이것은 도움이되었고 내 문제를 해결했습니다.

내가 궁금한 점은 (1) 셔플이 메모리 소비에 많은 영향을 미치는 이유와 (2) 전체 메모리 사용량이 프로세스 수 * 데이터 속성 크기보다 훨씬 많은 것처럼 보이는 이유입니다.

@bfreskura 의 예에서 self.data 의 크기는 24e7 정수로 대략 1.83GB입니다. 스크립트를 빠르게 실행할 수 있도록 24e5로 낮추면 데이터 개체의 크기는 대략 18.92MB입니다.

Python 목록의 경우 shuffle=False로 설정하면 프로세스가 298.17MB를 소비하는 것으로 측정됩니다. 그런 다음 shuffle=True로 설정하고 프로세스가 1.44GB를 소비하는 것으로 측정합니다.

따라서 18명이 넘는 작업자 + 1개의 주요 상위 프로세스, 모든 데이터가 모든 프로세스에 복사되더라도 최대 359.48MB의 추가 RAM만 있어야 합니다. shuffle=True일 때 그 양의 거의 4배가 되는 경우는 어떻게 됩니까? 순차 대 임의 메모리 액세스 및 결과적인 페이지 오류와 관련이 있어야 한다고 생각하지만 여기에서 무슨 일이 일어나고 있는지 더 정확하게 설명할 수 있는 사람이 있는지 궁금합니다.

@bfreskura 스크립트에 대한 내 수정 사항(CLI 실행 + 메모리 소비 보고)을 참조하려면 다음과 같이 하십시오.

https://gist.github.com/Erotemic/3f017de31529dc64c1a54948f37da1d5

랜덤 액세스는 파이썬이 객체 카운터를 메모리에 다시 쓰도록 하여 메모리 프레임의 기록 시 복사를 유발합니다. 순차 액세스는 변경되지 않은 카운터를 작성하지 않음으로써 잠재적으로 최적화될 수 있습니다(GC 주기에 따라 다름). 또한 작업자 수 *(모든 개체 크기 + 개체 수 * 파이썬 개체 포인터+카운터 크기)인 최대 사용량으로 추정하는 것이 훨씬 더 안전합니다(지금까지는). 우리는 현재 전체 메모리 복사를 방지하기 위한 솔루션을 연구하고 있지만 상당한 재설계가 필요하고 시간이 걸릴 것입니다.

@VitalyFedyunin 설명 감사합니다만 아직 잘 이해가 되지 않는 것 같습니다 :스마일:

목록 대신 numpy 배열, 예를 들어 np.string_ 유형의 정사각형 numpy 바이트 배열을 사용하여 위의 문제를 해결했지만 이제 webdataset(https:/ /github.com/tmbdev/webdataset/issues/24#issuecomment-709101119). 분명히 shm이 부족하지 않지만 @tmbdev 가 webdataset 스레드에서 앞서 지적했듯이 문제는 공유 메모리 세그먼트의 _숫자_일 수 있습니다...

이 문제 및/또는 관련 임시 해킹을 디버깅하는 방법에 대한 팁이 있습니까? 나는 ipcs를 시도했지만 그것은 나에게 유용한 것을 보여주지 못했습니다 (내 생각에). lsof /dev/shm 는 shm 개체 및 크기에 대한 정보를 보여주지만 그 의미가 무엇인지 잘 모르겠습니다...

저에게 proportional set size (pss in psutil)을 측정하면 문제의 크기를 측정하는 데 도움이 되었습니다. 사용자 지정 StringArray 및 DictArray 클래스로 이 문제를 해결했습니다.

@wangchust : @bashimao 가 제안한 솔루션은 적당히 큰(2,500만 개 이상의 텍스트 시퀀스) 데이터 세트에서도 아름답게 작동했습니다.

죄송합니다. github 사용에 대해 누락된 것이 있을 수 있지만 이 스레드에서 @bashimao 의 해결책은 없고 주석만 있습니다. 아무도 나에게 그것을 가리킬 수 있습니까?

@ alexander-soare https://github.com/pytorch/pytorch/issues/13246#issuecomment -617140519

np.string_ 로 캐스팅하는 것이 훨씬 간단합니다( str 등은 아님). 가지고 있다고

strings = ['hello', 'world']

그럼 해

strings_byte = np.array(strings).astype(np.string_)

그러면 결과는 단일 정사각형 바이트 배열이 됩니다(dtype 참고).

array([b'hello', b'world'], dtype='|S5')

그런 다음 str(strings_byte[0], encoding='utf-8') 와 같이 문자열을 선택할 때 문자열로 다시 인코딩해야 합니다.

이것은 작동하지 않습니다.

strings_byte = np.array(strings).astype(str)

dtype에 유의하십시오.

array(['hello', 'world'], dtype='<U5')

그것은 정사각형 바이트 배열, 즉 단일 객체가 아닙니다.

이 문제가 지속되고 나와 내 동료가 이 문제에 부딪힌 횟수를 고려할 때 이것이 원인인지 여부를 결정할 수 있는 방법이 있다면 도움이 될 것입니다. 이 스레드를 철저히 읽은 후 문제를 완화하기 위한 좋은 제안이 있는 것 같습니다(https://github.com/pytorch/pytorch/issues/13246#issuecomment-436632186, https://github.com/pytorch/pytorch/issues). /13246#issuecomment-612396143), 일부 혼란스러운 동작(https://github.com/pytorch/pytorch/issues/13246#issuecomment-708067670)도 있습니다.

1. 이 문제를 배제하기 위해 while True 루프에서 데이터 로더만 실행하고 메모리 사용량을 관찰하는 것으로 충분합니까? 루프가 실행될 때 메모리가 커지면 데이터 세트 개체에 개체를 축적하는 병리학적 동작이 있거나 이 문제가 발생하고 있다는 결론을 내릴 수 있다고 가정합니다.
2. 이 스레드에서 정말 이해할 수 없는 것은 몇 MB의 데이터만 보유하는 데이터 세트 클래스가 있는 경우 이것이 문제가 되는 이유입니다. 내가 올바르게 이해했다면 여기에 설명된 문제는 데이터 세트에서 액세스하는 모든 Python 개체가 결국 작업자 스레드의 메모리로 복사된다는 것입니다. 데이터 세트 클래스의 필드로 저장된 경로 목록에서 비디오를 로드하는 간단한 데이터 세트 클래스가 있는 경우 이것이 문제가 되는 이유는 무엇입니까? 공유 데이터는 무시할 수 있을 정도로 작습니다. 데이터 로더에서 shuffle=True 를 사용하면 https://github.com/pytorch/pytorch/issues/13246#issuecomment -708067670에 설명된 대로 메모리 사용량이 더 많아지는 이유는 무엇입니까?

나에게 맞는 솔루션 - https://t.me/snakers4/2577

나에게 맞는 솔루션 - https://t.me/snakers4/2577

이거 좋다! https://gist.github.com/vadimkantorov/86c3a46bf25bed3ad45d043ae86fff57 에서 내 방법의 유일한 장점은 DDP 프리미티브를 사용하여 DDP 작업자 간에 텐서로 가득 찬 개체를 공유할 수 있다는 것입니다(즉, 하나의 스레드에서만 거대한 데이터 세트 개체를 읽습니다. 그런 다음 텐서로 가득 찬 데이터 세트 개체를 다른 DDP 순위에 분산시킵니다. 같은 방식으로 DDP 마스터 작업자는 DDP 순위에서 텐서로 가득 찬 문자열 배열을 수집할 수 있습니다.

이 버그의 또 다른 실제 발생: https://github.com/NVIDIA/NeMo/issues/1467