德尔菲斯工程和支持是非常了不起的人。他们继续寻求解决方案，不管需要多少时间，也不管他们面临支持异构环境、硬件配置和客户需求的复杂挑战。这篇文章是为了支持我们的团队所做的努力，这项工作使以前受影响的solaris11.2集群配置变得稳定。Oracle的研究、修补、测试以及由此产生的认证是我们团队的一项巨大任务，我希望这些信息能为社区服务，但Delphix绝不推荐。这只是在我们的团队做出合理的系统使用决策后，为解决问题所做的工作。挑战环境：Solaris 11.3（SRU 17.5）+Oracle 12.2 RAC+ESX 5.5情况：在升级到12.2后，由于升级后对内存的新需求，环境遇到了严重的群集不稳定、内存不足。经过检查，发现许多特性比以前需要更多的内存，而系统根本没有办法支持它。由于我们的环境是12.2版的Solaris环境，我们需要从Oracle请求一个有文档记录的修补程序，以获得RAC性能和节点收回。该环境仍在经历节点收回，等等数据表明，我们必须将每个节点上的内存增加三倍才能像以前一样继续使用该环境。我们的家人不是那么容易放弃的人，所以我们进行了二次研究，以找出是否可以减少一些内存使用。我们发现，旧的可以再变新的。我的朋友，也是奥基人的同事，马克·菲尔丁（Marc Fielding）曾在博客上（以及其他帖子的链接，包括对另一个奥基人杰里米·施耐德（Jeremy Schneider）的赞誉）讲述了他在2015年将资源限制在12.1.0.2之后是如何限制资源的，这篇文章确实帮助了Delphix的工程师们度过了环境的最后一个高峰，即使在实现了解决内存泄漏的修补程序之后。在这里您将看到的大部分内容都来自于那篇文章，重点介绍了它在开发/测试系统中的使用（Delphix的最佳选择）研究内核内存失控从内核内存使用情况开始，可以使用mdb-k命令以百分比级别检查：我们也可以从另一个角度来看，使用kmsastat分解内核内存区域：Oracle ZFS ARC缓存接下来，Oracle ZFS有一个非常智能的缓存层，也称为ARC（自适应替换缓存）。无论是福是祸，ARC都会消耗尽可能多的可用内存，但如果需要，它应该将内存释放给其他应用程序。这个内存用于补充任何慢速磁盘I/O。在检查我们的环境时，大量内存被过度分配给ARC。这可能是由于oracle12.2的新版本，但是在集群中，内存不足可能是节点逐出的常见原因。我们可以在以下文件中检查弧的大小统计信息：这假设ZFS安装在/proc上，因此实际的arcstats文件可能位于与上面所示不同的路径位置。在文件内部，查看以下信息：c是弧的目标大小（以字节为单位）c_max是弧的最大大小（以字节为单位）size是弧的当前大小（以字节为单位）我们把剩下的东西都吃光了，带走了剩下的100%的内存，我们将在这篇文章的下一节中讨论。Oracle群集软件内存甲骨文集群软件是第三个被调查的轻率内存使用情况，可以削减。有一些明确记录的步骤可以用来调查Oracle的错误配置问题和功能问题，这些步骤可以帮助识别其中的许多问题。那么，在升级和修补之后，您可以做些什么来减少内存使用，以避免内存升级来支持集群升级？变化从没有为开发/测试环境提供好处的功能和安装列表中，列出了这些功能和安装的原因：更新了/etc/system文件，（需要重新启动，并且必须以root用户身份执行）：添加了set user_reserve_hint_pct=80进行此更改是为了限制ZFS对ARC缓存的内存量。当CRS进程无法分配内存时，对客户来说是一个重大问题。80%是在没有节点重新启动的情况下可以设置的最高百分比，这是我们都不希望发生的事情。已停止群集运行状况监视器（CHM）进程。这是12c集群软件中的一个全新的后台进程，它收集工作负载数据，在生产环境中，它的价值明显更高，但在开发和测试中呢？它很容易成为CPU和内存的后续消耗，可以更好地用于更多的虚拟数据库。为此，使用以下命令作为根用户：已删除跟踪文件分析器收集器（tfactl）。此后台进程将Oracle生成的许多跟踪文件收集到一个位置。很方便进行故障排除，但它是基于Java的，占用大量内存，并且容易受到Java堆问题的影响。使用以下命令将其卸载为群集的每个节点上的$ORACLE®HOME owner：已停止群集验证，（禁用CVU）。在以前的版本中，这是一个实用程序，可以手动添加到安装中，或者通过管理员执行post来解决问题。这是另一个简单地占用可重新分配给开发和测试环境的资源的功能，因此现在应该停止并禁用它，方法如下：其他变更减少了ASM实例的内存分配。12.2中的ASM实例现在使用1Gb内存，而以前的256Mb。这是一个巨大的变化，可能会影响其他依赖于该内存的特性。研究发现750Mb足够了，因此如果需要更多的内存重新分配，请考虑将每个节点上的内存降低到750Mb。要执行这组实例级参数更改，请在任何节点上运行以下操作，然后重新启动每个节点，直到集群已循环以使更改生效：对于大多数dba来说，CPU使用率高的特性可能会让大多数dba感到不安，但是当开发和测试数据库的开发和测试时，相对于生产环境而言，这些开发和测试数据库通常会获得较少的资源，因此一个更改通常可以提高这些环境的稳定性和使用寿命。在所有数据库中禁用高分辨率时间刻度，包括ASM数据库、常规数据库和网格基础设施管理存储库数据库（GIMR，SID为-MGMTDB）。高分辨率时钟是12c中的一个新特性，它们似乎会导致诸如VKTM这样的集群时间保持后台进程占用大量CPU。以下是禁用高分辨率刻度的SQL（必须在每个DB中运行一次）：经过所有这些更改后，团队发现Solaris内核仍比升级前消耗更多内存，但这更合理：Solaris内核：1GB RAMARC缓存：介于1–2GB之间Oracle群集软件：3Gb内存升级我们确实增加了内存，但没有预期的那么多。在所有的调整之后，我们仍然在为这三个特性使用超过5GB的内存，因此将每个节点从8GB增加到16GB，以确保有足够的资源支持升级后的所有开发和测试需求。我们想提供尽可能多的虚拟数据库（VDB）用于任何开发或测试所需的组，因此有一个超过3Gb的免费数据库是必须的！这次，Solaris集群不再经历内核死机、节点驱逐或意外重启，我们必须承认这是最重要的结果。向用户解释中断比为什么我们关闭并卸载未使用的功能到Oracle更困难…..）