Dask调度程序内存

随着时间的推移和执行的继续，我们的dask调度程序进程似乎在内存中膨胀。目前，我们看到它使用5GB的mem，这似乎很高，因为所有数据都应该存在于工作节点上：

  PID   USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
  31172 atoz      20   0 5486944 5.071g   7100 S 23.8 65.0  92:38.64 dask-scheduler

启动调度程序时，内存使用量将低于1GB。使用client.restart（）重新启动网络似乎没有帮助，只有杀死调度程序进程本身并重新启动才能释放内存

每个执行的任务的预期内存使用量是多少？ 调度器是否真的只维护指向包含未来结果的工作进程的指针

----编辑----

我想我主要关心的是为什么client.restart（）似乎没有释放调度程序进程正在使用的内存。很明显，我并不期望它释放所有内存，而是希望回到一个基本级别。我们正在使用client.map跨不同输入的列表执行我们的函数。在执行、反复执行客户机重启并拍摄调度程序内存快照后，我们看到以下增长：

PID用户PR NI VIRT RES SHR S%CPU%MEM TIME+命令
27955 atoz 20 0 670556 507212 13536 R 43.7 6.2 1:23.61 dask调度程序
27955 atoz 20 0 827308 663772 13536 S 1.7 8.1 16:25.85 dask调度程序
27955 atoz 20 0 859652 696408 13536 S 4.0 8.5 19:18.04 dask调度程序
27955 atoz 20 0 1087160 923912 13536 R 62.3 11.3 20:03.15 dask调度程序
27955 atoz 20 0 1038904 875788 13536 S 3.7 10.7 23:57.07 dask调度程序
27955 atoz 20 0 1441060 1.163g 12976 S 4.3 14.9 35:54.45 dask调度程序
27955 atoz 20 0 1646204 1.358g 12976 S 4.3 17.4 37:05.86 dask调度程序
27955 atoz 20 0 1597652 1.312g 12976 S 4.7 16.8 37:40.13 dask调度程序

我想我只是感到惊讶，在执行client.restart（）之后，我们没有看到内存使用回到某个基线

----进一步编辑---- 更多关于我们正在运行的内容的信息，因为建议如果我们传递大型数据结构，直接将它们发送给工作人员

我们为每个任务发送一个字典作为输入，当json转储dict时，大多数都少于1000个字符

----更进一步的编辑：再版---- 我们今天再次转载了这一期。我关闭了调度程序并重新启动了它，我们有大约5.4 GB的可用内存，然后我们运行了我将在下面粘贴的功能，该功能跨越69614个字典对象，这些对象实际上包含一些基于文件的信息（我们所有的工作人员都映射到相同的NFS数据存储，我们使用Dask作为分布式文件分析系统）

以下是函数（注意：squarewheels4是一个自制的惰性文件提取和分析包，它使用Acora和libarchive作为基础，用于从压缩存档中获取文件并为文件编制索引。）

取消期货交易时：

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21914 atoz      20   0 6257840 4.883g   2324 S  0.0 62.6 121:21.93 dask-scheduler

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.1G        248M        9.9M        415M        383M
Swap:          8.0G        4.3G        3.7G

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21914 atoz      20   0 6258864 5.261g   5144 R 60.0 67.5 122:16.38 dask-scheduler

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.5G        176M        9.4M        126M         83M
Swap:          8.0G        4.1G        3.9G

PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21914 atoz      20   0 6243760 5.217g   4920 S  0.0 66.9 123:13.80 dask-scheduler

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.5G        186M        9.4M        132M         96M
Swap:          8.0G        4.1G        3.9G

取消期货交易后：

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21914 atoz      20   0 6257840 4.883g   2324 S  0.0 62.6 121:21.93 dask-scheduler

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.1G        248M        9.9M        415M        383M
Swap:          8.0G        4.3G        3.7G

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21914 atoz      20   0 6258864 5.261g   5144 R 60.0 67.5 122:16.38 dask-scheduler

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.5G        176M        9.4M        126M         83M
Swap:          8.0G        4.1G        3.9G

PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
21914 atoz      20   0 6243760 5.217g   4920 S  0.0 66.9 123:13.80 dask-scheduler

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.5G        186M        9.4M        132M         96M
Swap:          8.0G        4.1G        3.9G

在执行完client.restart（）之后

不管我在分布式系统中运行了什么，我的期望是，在取消期货后，它至少会恢复到接近正常的状态……在执行client.restart（）之后，我们肯定会接近正常基线。我错了吗

---第二次复制---- 使用以下步骤再现行为（尽管不是完全的内存耗尽）：

这是我的worker函数

def get_fault_list_v2(file_dict):
    import libarchive
    return_dict = file_dict
    filename = "{file_path}{file_sha1}/{file_name}".format(**file_dict)
    with libarchive.file_reader(filename) as arc:
        for e in arc:
            pn = e.pathname
    return return_dict

我在68617个迭代/文件中运行了它

在运行之前，我们看到使用了这么多内存： PID用户PR NI VIRT RES SHR S%CPU%MEM TIME+命令 12256 atoz 20 0 1345848 1.107g 7972 S 1.7 14.2 47:15.24 dask调度程序

atoz@atoz-sched:~$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        3.1G        162M         22M        4.5G        4.3G
Swap:          8.0G        3.8G        4.2G

跑步之后，我们看到了很多：

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
12256 atoz      20   0 2461004 2.133g   8024 S  1.3 27.4  66:41.46 dask-scheduler

执行client.restart后，我们看到：

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
12256 atoz      20   0 2462756 2.134g   8144 S  6.6 27.4  66:42.61 dask-scheduler

---

一般来说，任务在调度程序上所占的空间应该小于1 KB。有一些事情可能会导致存储量显著增加，其中最常见的是在任务图中包含数据，如下所示

任务图中直接包含的数据存储在计划程序中。这通常发生在直接在诸如submit:

坏的 好

---

使用其他API也存在同样的原则。有关更多信息，我建议提供一个。否则很难提供帮助。

我更新了文章中的更多细节。我主要希望在这里设置我自己的期望，即dask调度程序在执行完任何执行后，然后执行客户端后应该使用多少内存。restart（）如果您能够提供一个最小的示例，其他人无需安装特殊软件或下载特殊数据即可轻松复制该示例，则可以更轻松地提供帮助。特别是，从问题回答者的角度来看，上的文档通常是理想的。第二次复制仅使用libarchive提供。上面的结果。

x = np.random.random(1000000)  # some large array
x = client.scatter(x)  # scatter data explicitly to worker, get future back
future = client.submit(np.add, 1, x)  # only send along the future