欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 健康 > 美食 > 250408_解决加载大量数据集速度过慢,耗时过长的问题

250408_解决加载大量数据集速度过慢,耗时过长的问题

2025/5/10 17:05:38 来源:https://blog.csdn.net/weixin_66378701/article/details/147080249  浏览:    关键词:250408_解决加载大量数据集速度过慢,耗时过长的问题

250408_解决加载Cifar10等大量数据集速度过慢,耗时过长的问题(加载数据时多线程的坑)

在做Cifar10图像分类任务时,发现每个step时间过长,且在资源管理器中查看显卡资源调用异常,主要表现为,显卡周期性调用,呈现隔一会儿动一下的情况(间隔时间过大导致不能同时截到两个峰值)。

image-20250408224446220

通过检测每步耗费时间发现,载入数据集的时间远远大于前向处理的时间。

在以下参数情况下

batch_size=16
num_workers=20 # 线程数

载入Cifai10数据集的时间为60s左右,前向计算时间仅为0.002s,浪费了大量的时间用于载入及传输数据。

image-20250408230936264

image-20250408225808623

先说结论,是多线程的问题,线程过多导致多线程冲突,修改num_workers=0即可解决问题

解决过程

修改过程中查阅很多资料和大佬博客,尝试了重新定义自己的dataset方法,将transform定义到初始化方法中,避免每获取一次数据就执行一遍transform,而是改为在把数据载入内存时一次全部处理完(详见解决pytorch中Dataloader读取数据太慢的问题_dataloader数据读取慢-CSDN博客)

然后重新定义自己加载数据的方法,大佬文中没给加载的方法,我这里补充

def data_loader(batch_size=4,num_workers=2):""":param batch_size: 批次大小:param num_workers: 线程数:return:train_loader:训练数据加载器test_loader:测试数据加载器class:分类类别"""root_dir="./data"transform=transforms.Compose([transforms.ToTensor(),transforms.Normalize((0.5,0.5,0.5),(0.5,0.5,0.5)),])train_dataset = CUDACIFAR10(root=root_dir,train=True,to_cuda=True,  # 使用XPU(或GPU)half=False,  # 不使用半精度浮点数download=True,  # 如果数据集尚未下载,则下载pre_transform=transform)trainloader = DataLoader(dataset=train_dataset,batch_size=batch_size,shuffle=True,num_workers=num_workers)test_dataset = CUDACIFAR10(root=root_dir,train=False,to_cuda=True,  # 使用XPU(或GPU)half=False,  # 不使用半精度浮点数download=True,  # 如果数据集尚未下载,则下载pre_transform=transform)testloader = DataLoader(dataset=test_dataset,batch_size=batch_size,shuffle=True,num_workers=num_workers)classes=('plane','car','bird','cat','deer','dog','frog','horse','ship','truck')return trainloader,testloader,classes

然后加载数据集发现报错:

RuntimeError: _share_filename_: only available on CPU

多线程加载仅支持在cpu上进行,我们这样的处理方法已经提前将数据载入到gpu或xpu上,无法使用多线程,遂将num_workers修改为0,发现问题解决了。数据载入速度变得很快。遂准备复现并记录问题,发现把大佬数据类代码注释后,使用官方cifar10数据类代码,加载速度仍较快,核实发现应该是多线程的问题。

尝试多组参数

batch_size=16
num_workers=0

每个step执行时间为11-12s左右

image-20250408231515083

调整参数

batch_size=32
num_workers=1

此时显卡调用情况为长矩形,持续调用,但占用率并不高,在33-34左右波动

image-20250408231417767

此时显卡占用情况呈现连续峰谷,占用波峰为50左右,每个step执行时间缩短为6-8秒

image-20250408231738784

image-20250408231815123

因显卡调用仍有间隙,尝试增大batchsize

batch_size=64
num_workers=1

显卡占用情况仍呈现连续峰谷,占用波峰为30左右,每个step执行时间缩短为6-7秒

image-20250408232021771

image-20250408232055250

batch_size进一步放大到128,显卡占用波峰继续缩小为20左右,但每个step的时间未明显降低

尝试64与2的搭配,仍与32与1的搭配执行时间及显卡占用大致相同,执行时间误差1s,占用误差50%。

尝试128与2的搭配,结果与64,1的搭配情况大致相同,得结论,与比值有关。

batch_sizenum_workers每个step执行时间(秒)显卡占用情况描述显卡占用率波峰(%)性能优化效果(与初始参数对比)
162070显卡周期性调用,间隔时间过长,不能充分利用显卡资源,大部分时间在等待数据加载-数据载入时间过长,显卡资源浪费严重
16011-12显卡调用情况为长矩形,持续调用,但占用率不高,波动在33-34%左右33-34数据载入速度显著提高,显卡资源利用率有所提升,但仍有提升空间
3216-8显卡调用情况呈现连续峰谷,占用波峰约为50%50数据载入速度进一步提高,显卡资源利用率提升,step执行时间缩短
6416-7显卡调用情况仍呈现连续峰谷,占用波峰约为30%30数据载入速度进一步提高,显卡资源利用率提升,step执行时间进一步缩短
1281未明显降低显卡占用波峰继续缩小为20%左右20数据载入速度未明显提升,显卡资源利用率降低,step执行时间未明显缩短
642与32,1搭配大致相同与32,1搭配大致相同-与32,1搭配大致相同,执行时间误差1秒,占用误差5%
1282与64,1搭配大致相同与64,1搭配大致相同-

batch_sizenum_workers 的比值对性能影响较大,需要根据具体情况进行调整。在测试中,batch_size=32, num_workers=1batch_size=64, num_workers=1 的搭配效果较好,能够在数据载入速度和显卡资源利用率之间取得较好的平衡

进一步思考

发现若如所测数据,

image-20250408233454914

仍有大量时间浪费在cpu与gpu的通信及其他步骤上

使用前文所提到的大佬的数据类初始化方法(避免多次transform),在batch_size=16num_workers=0的参数基础上,测得单次step时间可压缩到7-8s,即节省3-4s。其余参数大家自行尝试。

image-20250408233928137

本人初学小白,如有错误劳烦大佬指正

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

热搜词