[Bug] meta数据load进来内存过大，训练过程中内存持续增长

[Cerberous]

Describe the bug

您好，请问一下有更合理的数据处理方式嘛？现在的meta当数据量很大的时候meta会占据很多内存，每张卡都读进来的情况下直接就翻了8倍，而且在训练的过程中内存仍然在一直的增长，增长的比例还是挺高的，请问是bug还是其他问题？

Environment

官方的镜像环境

Other information

No response

[Guoteng]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。
2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

[Cerberous]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

[Guoteng]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。
最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

[Cerberous]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。 最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

非常感谢，我试试看，非常感谢您的回复非常有用

[jiaxingli]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。 最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

非常感谢，我试试看，非常感谢您的回复非常有用

通过共享内存读取meta的功能已实现，开关在config.data.use_shm，默认为False。gc的位置也已更新。#255

[Cerberous]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。 最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

非常感谢，我试试看，非常感谢您的回复非常有用

通过共享内存读取meta的功能已实现，开关在config.data.use_shm，默认为False。gc的位置也已更新。#255

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。 最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

非常感谢，我试试看，非常感谢您的回复非常有用

通过共享内存读取meta的功能已实现，开关在config.data.use_shm，默认为False。gc的位置也已更新。#255

meta的功能已实现，确实解决了上述的问题，第二个问题就是内存仍然在缓慢上升，我已经把gc.disable()移动到了创建dataloader之后，有个问题是为什么训练小模型interval反而调的大，大模型的internval反而调的小呢？我自己的理解是大模型需要训练更久，所以为了训练更快interval需要设置的更长？我现在是interval设置成了10000

[jiaxingli]

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。 最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

非常感谢，我试试看，非常感谢您的回复非常有用

通过共享内存读取meta的功能已实现，开关在config.data.use_shm，默认为False。gc的位置也已更新。#255

hi您好 @Cerberous ，非常感激您能使用intenevo进行训练

1. 第一个meta会占据很多内存问题，这个问题确实目前是存在的，这个我们在内部仓库有一个实现了单机多进程共享meta文件的dataset，预期这周就会迁移到开源仓库里，希望可以解决你的问题。

2. 第二个内存持续增长的问题，请问您是观察的free -h中哪一列的内存指标呢？如果是buff/cache在一直增长的话是正常的，这是因为mmap会不断进行，导致pagecache上升，但这些内存是可以被操作系统驱逐的，所以不用太关注。但如果used内存一直在持续增长的话确实不太正常，可能和我们之前发现的一个gc bug有关，这个我后续会check下。

非常感谢您的回答，如果开源了我第一时间尝试下，内存增长的问题是free -h的used内存一直在缓慢增长，应该和gc disable掉并且和empty_cache那个函数有关？

对的，您可以试下把gc.disable()从这里移到train.py中dataloader创建之后，训练循环开始之前，比如这里，这样dataloader创建的子进程会正常的gc，我们只禁掉主进程的自动gc功能，这样内存应该就不会一直上升了。 最后您可以试下调整empty_cache_and_diag_interval的值，这个值会控制我们调用gc.collect()的频率，他会让训练变得很慢，所以建议对于小模型可以设置较大的间隔（比如500-1000），对于大模型间隔设置的较小的间隔（比如50-100）

非常感谢，我试试看，非常感谢您的回复非常有用

通过共享内存读取meta的功能已实现，开关在config.data.use_shm，默认为False。gc的位置也已更新。#255

meta的功能已实现，确实解决了上述的问题，第二个问题就是内存仍然在缓慢上升，我已经把gc.disable()移动到了创建dataloader之后，有个问题是为什么训练小模型interval反而调的大，大模型的internval反而调的小呢？我自己的理解是大模型需要训练更久，所以为了训练更快interval需要设置的更长？我现在是interval设置成了10000

因为小模型每个step跑的比较快，需要释放的东西不多，可以多等些step。而大模型单个step运行时间较长，step内需要释放的东西也更多，所以间隔更小。