问题标签 [tcmalloc]

我试图在 Visual Studio 2013 中使用 tcmalloc 编译一个项目。我已经从gperftools包中编译了 libtcmalloc 的 .lib 文件，并将 libtcmalloc.lib 添加到链接器输入选项中。

当我尝试构建我的项目时，我收到以下错误：

如果我从链接器选​​项中删除 libtcmalloc.lib，项目编译得很好..

我在 ubuntu 14.04 服务器 64 位上运行 mongodb 3.2。mongodb 服务器不断崩溃。每当我重新启动服务器时，我都会看到：

同样在此之后运行 mongo shell 时，我收到以下错误：

在我的系统上以前没有发生过这种情况。我该如何纠正这个错误？它每2-3小时不断发生。

完整的 MongoDB 日志文件：在此处下载

EDIT1：添加了 mongodb 日志文件。

我正在阅读 Google 的 TCMalloc 源代码（Windows 移植）。

正如您在上面的代码片段中pagesize看到的那样（即分配单位）被计算为 dwPageSize 和 dwAllocationGranularity 之间的最大值。我的意思是要知道这两个值之间的关系：是否有必要按照这里向上解释的方式计算值？是否存在 dwPageSize 可能大于 dwAllocationGranularity 的情况？

经过几天的测试，我发现运行时修补机制patch_functions.cc在生产环境中使用并不安全。 除了 HeapAlloc() 和 HeapFree() 之外，它似乎在 VS2010 项目中运行良好，但由于一些未解决的问题Open Issues
无法在 VS2015 项目中使用。Windows 自述文件描述了这种使用 tcmalloc 的替代方法：

以上所有方法的替代方法是将您的应用程序与 libc 静态链接，然后将其 malloc 替换为 tcmalloc。这使您可以正常构建和链接程序；tcmalloc 支持来自后处理步骤。这比上述技术更可靠（它依赖于运行时补丁，它本质上是脆弱的），尽管需要做更多的工作。有关详细信息，请参阅 https://groups.google.com/group/google-perftools/browse_thread/thread/41cd3710af85e57b

不幸的是，所提供的点赞是不可取的，似乎谷歌已经关闭了该组。

有人可以解释一下我该怎么做吗？

我想知道 gcc 的 -fsanitize=address 选项是否适用于 tcmalloc？还是我们需要通过禁用 tcmalloc 来运行？或者如果运行消毒剂启用 tcmalloc 会很好吗？

我正在 Cray 上构建 NWChem。我的 Cray 环境中的 cc 已将 libtcmalloc_minimal 添加到存档文件中。在我的配置例程中，它显式地附加了第二个 -ltcmalloc_minimal 导致多重定义和配置失败。但是没有任何 configure.* 文件或 makefile（或NWChem 包含的任何文件）包含对 tcmalloc_minimal 的任何引用。

• tcmalloc_minimal 是如何进入那里的？
• 我怎样才能把它挡在外面？

如何在 Google Cloud ML Engine 上使用 TCMalloc？或者除了 TCMalloc 之外，还有没有其他方法可以解决 ML Engine 上的内存泄漏问题？

完成图表似乎没有帮助。

内存利用率图：

训练 73 个 epoch 后，我出现了内存不足错误。这是训练日志的一部分：

11:26:33.707 作业失败。

11:26:20.949 完成拆除 TensorFlow。

11:25:18.568 副本 master 0 内存不足并以非零状态 247 退出。要了解有关您的作业退出原因的更多信息，请查看日志

11:25:07.785 清理完毕。

11:25:07.785 模块完成；打扫干净。

11:25:07.783 模块因未能调用子进程命令而引发异常命令 '['python', '-m', u'trainer.main', u'--data=gs://', u'-- train_log_dir=gs://tfoutput/joboutput', u'--model=trainer.crisp_model', u'--num_threads=32', u'--memory_usage=0.8', u'--max_out_norm=1', u '--train_batch_size=64', u'--sample_size=112', u'--num_gpus=4', u'--allow_growth=True', u'--weight_loss_by_train_size=True', u'-x',返回非零退出状态 -9。

11:23:08.853 PNG 警告：扩展块时超出大小限制

11:18:18.474 纪元 58.0：准确度 = 0.9109

11:17:14.851 2017-05-17 10:17:14.851024: epoch 58, loss = 0.12, lr = 0.085500 (228.9 examples/sec; 0.280 sec/batch)

11:15:39.532 PNG 警告：扩展块时超出大小限制

11:10:23.855 PoolAllocator：372618242个get请求后，put_count=372618151 evicted_count=475000 eviction_rate=0.00127476，不满足分配率=0.00127518

11:05:32.928 PNG 警告：扩展块时超出大小限制

10:59:26.006 纪元 57.0：准确度 = 0.8868

10:58:24.117 2017-05-17 09:58:24.117444: epoch 57, loss = 0.23, lr = 0.085750 (282.2 examples/sec; 0.227 sec/batch)

10:54:37.440 PNG 警告：扩展块时超出大小限制

10:53:30.323 PoolAllocator：366350973个get请求后，put_count=366350992 evicted_count=465000 eviction_rate=0.00126927和不满足分配率=0.0012694

10:51:51.417 PNG 警告：扩展块时超出大小限制

10:40:43.811 纪元 56.0：准确度 = 0.7897

10:39:41.308 2017-05-17 09:39:41.308624: epoch 56, loss = 0.06, lr = 0.086000 (273.8 examples/sec; 0.234 sec/batch)

10:38:14.522 PoolAllocator: 360630699 次获取请求后，put_count=360630659 evicted_count=455000 eviction_rate=0.00126168 和不满足分配率=0.00126197

10:36:10.480 PNG 警告：扩展块时超出大小限制

10:21:50.715 纪元 55.0：准确度 = 0.9175

10:20:51.801 PoolAllocator：354197216个get请求后，put_count=354197255 evicted_count=445000 eviction_rate=0.00125636和不满足分配率=0.00125644

10:20:49.815 2017-05-17 09:20:49.815251: epoch 55, loss = 0.25, lr = 0.086250 (285.6 examples/sec; 0.224 sec/batch)

10:02:56.637 纪元 54.0：准确度 = 0.9191

10:01:57.367 2017-05-17 09:01:57.367369: epoch 54, loss = 0.09, lr = 0.086500 (256.5 examples/sec; 0.249 sec/batch)

10:01:42.365 PoolAllocator：347107694个get请求后，put_count=347107646 evicted_count=435000 eviction_rate=0.00125321和不满足分配率=0.00125354

09:45:56.116 PNG 警告：扩展块时超出大小限制

09:44:12.698 纪元 53.0：准确度 = 0.9039

09:43:09.888 2017-05-17 08:43:09.888202: epoch 53, loss = 0.10, lr = 0.086750 (307.0 examples/sec; 0.208 sec/batch)

09:41:48.672 PoolAllocator：339747205 次获取请求后，put_count=339747210 evicted_count=425000 eviction_rate=0.00125093 和不满意的分配率=0.00125111

09:36:14.085 PNG 警告：扩展块时超出大小限制

09:35:11.686 PNG 警告：扩展块时超出大小限制

09:34:45.011 PNG 警告：扩展块时超出大小限制

09:31:03.212 PNG 警告：扩展块时超出大小限制

09:28:40.116 PoolAllocator：335014430 次获取请求后，put_count=335014342 evicted_count=415000 eviction_rate=0.00123875 和不满足分配率=0.00123921

09:27:38.374 PNG 警告：扩展块时超出大小限制

09:25:23.913 PNG 警告：扩展块时超出大小限制

09:25:16.065 纪元 52.0：准确度 = 0.9313

09:24:16.963 2017-05-17 08:24:16.962930: epoch 52，损失 = 0.11，lr = 0.087000（278.7 示例/秒；0.230 秒/批次）

09:17:48.417 PNG 警告：扩展块时超出大小限制

09:13:34.740 PoolAllocator: 329380055 次获取请求后，put_count=329379978 evicted_count=405000 eviction_rate=0.00122958 和不满足分配率=0.00123001

09:06:09.948 更新纪元 51.0：准确度 = 0.9357

09:06:09.948 纪元 51.0：准确度 = 0.9357

09:05:09.575 2017-05-17 08:05:09.575641: epoch 51，损失 = 0.11，lr = 0.087250（248.4 示例/秒；0.258 秒/批次）

08:59:17.735 PNG 警告：扩展块时超出大小限制

08:55:58.605 PoolAllocator：322904781个get请求后，put_count=322904714 evicted_count=395000 eviction_rate=0.00122327和不满足分配率=0.00122368

08:48:46.322 PNG 警告：扩展块时超出大小限制

08:47:27.936 纪元 50.0：准确度 = 0.9197

08:46:29.370 2017-05-17 07:46:29.370135: epoch 50, loss = 0.20, lr = 0.087500 (253.2 examples/sec; 0.253 sec/batch)

我已经尝试在本地机器上使用 TCMalloc 进行培训，但仍然存在内存泄漏，但少于不使用它。

我的推理是，如果 tcmalloc 维护一个每个线程的空闲列表，从该列表下面可以满足动态分配，那么 tcmalloc 在平均情况下的性能应该非常接近堆栈分配（调整池大小的成本分摊到许多操作）。

这在实际操作中是否成立？有没有我没有想到的退化案例？

CentOS Linux 版本 7.3.1611

gcc 版本 4.8.5 20150623

gperftool 2.4-8.el7

1. 链接 -ltcmalloc 的我的 c++ 程序在没有 HEAPCHECKER 或 HEAPPROFILE 的情况下工作正常。它使用的内存稳定在5M~10M。

2.如果我使用带有env HEAPCHECKER=NORMAL的heap-checker 运行程序，则内存每小时增加约 50M 直到 OOM 杀手。

3.如果我使用带有env HEAPPROFILE="./hp" HEAP_PROFILE_ALLOCATION_INTERVAL=100000000的堆配置文件，内存每40分钟增加约100M，并且还会触发OOM。但是，当我使用pprof分析堆文件时，它会显示总内存只有 0.1MB，我预计是 100M。

我知道 heap-checker 和 heap-profile 会导致额外的内存使用，因为它们需要记录一些其他信息来跟踪内存分配，但我认为这不是我的情况的原因。

我将 heap-checker 和 heap-profile 与另一个小程序一起使用，效果很好。

这两个程序最大的区别是，故障程序使用协程，我的意思是函数swapcontext、getcontext和makecontext。

我的问题是：

Q1.为什么我设置HEAP_PROFILE_ALLOCATION_INTERVAL=100000000时pprof打开的堆文件显示总内存为0.1M？

Q2. heap-checker 或 heap-profile 是否可能与这些协程函数不能很好地配合？

我正在训练一个用 TF 构建的模型。在第一个时期，TF 比下一个时期慢 *100 倍，我看到如下消息：

I tensorflow/core/common_runtime/gpu/pool_allocator.cc:259] Raising pool_size_limit_ from 958 to 1053

正如这里所建议的，我尝试通过设置来使用 tcmalloc LD_PRELOAD="/usr/lib/libtcmalloc.so"，但它没有帮助。

关于如何使第一个时代运行得更快的任何想法？