[Bug]: clean_links_mapper、clean_ip_mapper等算子导致OOM

[YaboSun]

Before Reporting 报告之前

• I have pulled the latest code of main branch to run again and the bug still existed. 我已经拉取了主分支上最新的代码，重新运行之后，问题仍不能解决。

• I have read the README carefully and no error occurred during the installation process. (Otherwise, we recommend that you can ask a question using the Question template) 我已经仔细阅读了 README 上的操作指引，并且在安装过程中没有错误发生。（否则，我们建议您使用Question模板向我们进行提问）

Search before reporting 先搜索，再报告

• I have searched the Data-Juicer issues and found no similar bugs. 我已经在 issue列表 中搜索但是没有发现类似的bug报告。

OS 系统

Ubuntu20.04

Installation Method 安装方式

from source

Data-Juicer Version Data-Juicer版本

latest

Python Version Python版本

3.10.12

Describe the bug 描述这个bug

清洗英文web数据，数据规模约150G左右，开启以下算子：

  - clean_email_mapper:                                     # remove emails from text.
  - clean_html_mapper:                                      # remove html formats form text.
  - clean_ip_mapper:                                        # remove ip addresses from text.
  - clean_links_mapper:                                     # remove web links from text.

清洗过程占用内存达1.4TB导致OOM

To Reproduce 如何复现

详细配置文件如下：

project_name: 'xxx'
dataset_path: 'xxx'
export_path: 'xxx'

np: 128  
open_tracer: true
text_keys: 'text'
trace_num: 0x3f3f3f3f

process:
  - words_num_filter:                                     
      lang: en                                              
      tokenization: false                                    
      min_num: 100                                            
  - clean_email_mapper:                                     
  - clean_html_mapper:                                      
  - clean_ip_mapper:                                       
  - clean_links_mapper:                                     
  - perplexity_filter:
      lang: en
      max_ppl: 2500 
  - document_minhash_deduplicator:                          
      tokenization: space                                    
      window_size: 5                                          
      num_permutations: 256                                   
      jaccard_threshold: 0.7                                 
      num_bands: null                                        
      num_rows_per_band: null                                 
      lowercase: false                                         
      ignore_pattern: null                                    
  - word_repetition_filter:
      lang: en
      tokenization: true
      rep_len: 10
      max_ratio: 0.1  

Configs 配置信息

No response

Logs 报错日志

No response

Screenshots 截图

No response

Additional 额外信息

No response

[HYLcool]

你好，感谢你的关注与使用！

请问有具体的log信息吗？比如是在哪一个算子的处理过程当中产生的OOM错误，如能提供相关信息对我们定位具体原因有很大帮助~

此外，我们注意到你在处理时使用了较高的并行度（np=128），你可以将其减小后再进行尝试；以及注意到你开启了tracer，trace_num设置为了一个非常大的值，由于在tracer工作过程当中，有变化的样本是先存放在内存中然后导出到磁盘的，它需要占用额外的时间和内存，建议你这个值设置为一个较小的值，毕竟tracer只是帮助你去采样并了解OP的处理效果，

[YaboSun]

你好，感谢你的关注与使用！

请问有具体的log信息吗？比如是在哪一个算子的处理过程当中产生的OOM错误，如能提供相关信息对我们定位具体原因有很大帮助~

此外，我们注意到你在处理时使用了较高的并行度（np=128），你可以将其减小后再进行尝试；以及注意到你开启了tracer，trace_num设置为了一个非常大的值，由于在tracer工作过程当中，有变化的样本是先存放在内存中然后导出到磁盘的，它需要占用额外的时间和内存，建议你这个值设置为一个较小的值，毕竟tracer只是帮助你去采样并了解OP的处理效果，

感谢回复，具体log没有打印报错信息，观察内存占用很高导致Kill -9，,我做了几个实验尝试：

• 如您所说将并行度降低到了20，尝试后没有任何作用，还是OOM
• 之后将所有clean_links_mapper等相关mapper算子都去掉，只保留其余4个算子，可以正常运行，且内存占用在600G左右

[HYLcool]

将trace_num设置为一个较小的值（如默认的10）能否避免OOM呢？

[YaboSun]

将trace_num设置为一个较小的值（如默认的10）能否避免OOM呢？

设置了1000还是不行，内存基本没有太大变化

[HYLcool]

好的，请问你方便提供你的待处理的数据吗（可邮件告诉我们数据获取方式，邮箱: lielin.hyl@alibaba-inc.com）？

不方便的话可以额外提供一下数据集的样本数目，以及这个数据集的大概类型（比如类似于common crawl之类的），以及别的一些你觉得有帮助的信息，然后我们这边尝试复现一下你遇到的这个问题

[YaboSun]

好的，请问你方便提供你的待处理的数据吗（可邮件告诉我们数据获取方式，邮箱: lielin.hyl@alibaba-inc.com）？

不方便的话可以额外提供一下数据集的样本数目，以及这个数据集的大概类型（比如类似于common crawl之类的），以及别的一些你觉得有帮助的信息，然后我们这边尝试复现一下你遇到的这个问题

就是common crawl的一部分英文数据集，大概180G，总量在2500w条左右

[HYLcool]

嗨，我们这边对齐你这边的情况用CC的数据构造了一个数据集，大小189GB，包括25,359,505个数据样本

然后在一台754GB内存的机器上用与你的算子列表相同的流程对数据集进行处理，np设置为了48，tracer开启，trace_num设置为1000，结果能够正常处理完成。实验机器在未处理时内存水位为180GB左右（有其他实验在同时运行），基于此，你提到的4个mapper算子在处理的过程中峰值内存占用分别为：

• clean_email_mapper: 283GB
• clean_html_mapper: 288GB
• clean_ip_mapper: 282GB
• clean_links_mapper: 277GB

四个算子占用内存均为超过系统内存，均能够正常处理完成。因此我们这边未能复现出你遇到的OOM的问题。

清洗过程占用内存达1.4TB导致OOM

再请问你一下，你上文所说的这个“占用内存”具体指的是下面的哪一个？

• 随机访问存储RAM：在你的系统中可以使用free -h获取机器的总内存，上面的复现实验中的内存即指这个内存
• 硬盘存储：在你的系统中可以使用df -h获取机器中个磁盘/文件系统的存储使用情况

[github-actions]

This issue is marked as stale because there has been no activity for 21 days. Remove stale label or add new comments or this issue will be closed in 3 day.

[github-actions]

Close this stale issue.