问题标签 [contention]

我创建了一个应用程序，在给定足够数据的情况下，它无法完成，并显示“由于 'ACTIVE_TRANSACTION'，数据库 'tempdb' 的事务日志已满。” 和“找不到表 0”。

报告使用的存储过程没有显式引用“tempdb”，因此它必须是 SQL Server 自己管理的东西。

无论如何，我通过分析 > 性能和诊断在 Visual Studio 2013 中运行了“资源争用”分析。

完成后，它在“并发分析报告”中告诉我，总共有 30,790 个争用，“Handle2”和“Multiple Handles 1”占“最争用资源”和“_CoreExeMain”的 99% 以上，线程 ID 4936 成为“最具争议的话题”

我想这一切都很有趣，但现在我知道了，我能做些什么呢？

30,790 的总争用量是否过多？听起来像，但我不知道。但同样，假设是这样，这些信息似乎并不能告诉我任何有价值的东西，即：我能做些什么来改善这种情况？如何以编程方式防止或限制资源和/或线程争用？

生成的报告中没有错误，这六条消息属于“仅供参考”类型。有一个警告：

警告 1 DA0022：# Gen 1 Collections / # Gen 2 Collections = 2.52；Gen 2 垃圾回收的发生率相对较高。如果按照设计，您的程序的大部分数据结构都被分配并保留了很长时间，那么这通常不是问题。但是，如果这种行为是无意的，您的应用程序可能会固定对象。如果您不确定，您可以收集 .NET 内存分配数据和对象生存期信息，以了解您的应用程序使用的内存分配模式。

...但是数据结构“长时间”的持久化确实是设计使然。

更新

然后我运行了“.NET 内存分配”报告，在这里我也不知道该怎么做：

1.24 亿字节是否过多？分配最多内存的函数有什么不好的，或者哪些类型分配的内存最多？

我也不明白为什么在生成报告后红色垂直线会移动；它首先在“616”附近，然后移至 0（如上面的屏幕截图所示），现在大约为 120。

更新 2

我现在看到（在运行最终性能检查（仪器）之后）垂直的红线只是一个旅鼠——无论你在哪里拖动它，它都会跟随光标。这是有目的的，我猜...

一位同事最近遇到了一个问题，归结为我们认为具有两个线程的 C++ 应用程序中的以下事件序列：

• 线程 A 持有一个互斥锁。

• 当线程 A 持有互斥体时，线程 B 尝试锁定它。由于它被持有，线程 B 被挂起。

• 线程 A 完成了它持有互斥锁的工作，从而释放了互斥锁。

• 此后不久，线程 A 需要访问受互斥锁保护的资源，因此它再次锁定它。

• 似乎线程 A 再次获得了互斥锁；线程 B 仍在等待，即使它首先“请求”锁定。

这一系列事件是否符合 C++11std::mutex和/或 pthread 的语义？老实说，我以前从未考虑过互斥锁的这一方面。

是否有任何公平保证可以防止其他线程饥饿太久，或者有什么方法可以得到这样的保证？

如果没有足够的 tempdb 可用，我想以一种返回错误消息的方式运行我的大部分查询。

有没有办法做到这一点？

等待 tempdb 有更多空间的默认行为。但这是没用的，因为如果其他进程同时使用 tempdb，它们会相互死锁。

我们开发了一个大型 C++ 应用程序，它可以在大型 Linux 和 Solaris 机器上的多个站点上令人满意地运行（多达 160 个 CPU 内核甚至更多）。这是一个高度多线程（1000+ 线程）、单进程架构，消耗大量内存（200 GB+）。我们正在对 Google Perftool 的 tcmalloc（或 Solaris 上的 libumem/mtmalloc）进行 LD_PRELOAD 处理，以避免内存分配性能瓶颈，通常效果良好。但是，我们开始看到内存分配/释放期间锁争用对一些较大的安装的不利影响，尤其是在进程运行了一段时间之后（这暗示了分配器的老化/碎片效应）。

我们正在考虑更改为多进程/共享内存架构（重分配/释放不会发生在共享内存中，而是在常规堆上）。

所以，最后，这是我们的问题：我们能否假设现代 Linux 内核的虚拟内存管理器能够有效地将内存分配给数百个并发进程？或者我们是否必须预期会遇到与我们在单进程/多线程环境中看到的相同类型的内存分配争用问题？我倾向于希望获得更好的整体系统性能，因为我们将不再局限于单个地址空间，并且拥有多个独立地址空间将需要更少的虚拟内存管理器锁定。有人有比较多线程与多进程内存分配的实际经验或性能数据吗？

我有几个运行虚拟机的 Docker 容器，我想在所有容器中统一限制磁盘 I/O 吞吐量 20%，而不会对机器上的其他资源（即 CPU）施加任何压力。

我知道我可以通过更改每个容器的 blkio 重量来更改 cgroup；但是，Docker 容器具有这样的特性，即即使您限制了某个资源的使用，如果没有其他进程争用该资源，它也会使用超过该限制（也许有办法将其关闭？）。

一种解决方案是简单地启动另一个进行任意磁盘读取的进程（例如，通过 dd）。但是，dd 也会占用大量 CPU，因此这是不可取的。

总结我的问题，我正在寻找一种在不使用任何其他资源的情况下限制磁盘读取利用率的方法。

我们遇到许多线程在下面拥有 ClassLoader 锁的线程后面等待，如图所示。

这发生在在 IBM JDK 1.7 上运行的 Weblogic 10.3.6 上。

我曾考虑将 Weblogic JAX-WS 实现换成较新的实现，但希望有一些证据表明它将在开始这条道路之前解决问题。

我也在这里看到这个 JAX-WS 客户端调用线程安全吗？代理类不是线程安全的。使用代理类的 ThreadLocal 实例怎么样？还是类似于 KryoPool 的代理类池？

https://github.com/EsotericSoftware/kryo/blob/master/src/com/esotericsoftware/kryo/pool/KryoPool.java

监视器

Java 堆栈

我在集群模式下使用 4 个实例的石英 1.8.6。现在，我观察到表 QRTZ_LOCKS 的争用很高。我的应用程序还为在线客户提供网络服务。该网络服务还可以安排新作业。现在，我在这些 web 服务上看到了超时异常，因为当他们想要安排新作业时，他们等待太久才能获得 QRTZ_LOCKS 表的锁定。对我来说，为 web 服务建立 100% 可靠的操作很重要（比石英作业操作更重要）。是否可以仅在 1 个实例上启动石英作业运行器，而其他 3 个实例配置为 org.quartz.jobStore.isClustered=false 以允许它们执行调度而不锁定 QRTZ_LOCKS？

更新：实际上，如果我打算只使用作业运行器运行一个实例，而所有其他实例只允许添加新作业，那么这将不再是一个集群。所以，实际的问题是：是否可以为所有 4 个实例配置 org.quartz.jobStore.isClustered=false，只让 1 个实例运行作业，但允许所有 4 个实例将新作业调度到同一个 jdbc 存储？

从书中引用java并发实践：

同步的性能成本来自多个来源。synchronized 和 volatile 提供的可见性保证可能需要使用称为内存屏障的特殊指令，这些指令可以刷新或使缓存无效、刷新硬件写入缓冲区和停止执行管道。内存屏障也可能会产生间接的性能影响，因为它们会抑制其他编译器优化；大多数操作不能用内存屏障重新排序。在评估同步的性能影响时，区分竞争同步和非竞争同步很重要。同步机制针对无竞争的情况进行了优化（volatile 始终是无竞争的)，在撰写本文时，对于大多数系统而言，“快速Ͳpath”无竞争同步的性能成本范围为 20 到 250 个时钟周期。

你能更清楚地澄清这一点吗？如果我有大量线程读取 volaile 变量怎么办？

你能提供争用定义吗？

是否有衡量争用的工具？它是在哪些价值观中衡量的？

我正在使用 STM32F4xx 控制器。我使用 DMA 来缓冲 UART（循环缓冲区）。我担心的是，当我的程序与 DMA 同时访问相同的内存位置时，是否会出现内存争用。

争用是否会以这种方式发生，或者控制器是否有措施防止这种情况发生？

谢谢。

我们有一个用例，我们的数据在一段时间后变得陈旧。因此我们选择 expireAfterWrite 缓存驱逐策略。但是，这会导致线程池中的线程过多。知道为什么会发生这种情况以及是否有任何方法可以避免这种情况。

示例线程池日志：