湖南建设网站公司,大白兔网络营销策划书,江门网站推广哪家好,新手做网站怎么上传系统几周前#xff0c;我获得了一个难得的机会#xff0c;可以在基础设施领域弄脏双手。 在JVM内部的深入了解下#xff0c;我每天的工作经历发生了有趣的变化#xff0c;我想与您分享动机和成果。 希望它可以启发类似的问题类别。 背景 我将从解释需要解决方案的上下文开始。… 几周前我获得了一个难得的机会可以在基础设施领域弄脏双手。 在JVM内部的深入了解下我每天的工作经历发生了有趣的变化我想与您分享动机和成果。 希望它可以启发类似的问题类别。 背景 我将从解释需要解决方案的上下文开始。 如果您知道Plumbr性能监控的全部内容则可以跳过此部分。 对于其他所有人我们Plumbr都在构建性能监控解决方案。 我们的方法是独特的因为我们旨在使所有性能问题都具有源代码的根本原因。 此类问题的最复杂类别之一是其根源隐藏在Java内存分配和管理中。 此类别中的问题包括 内存不足 面临太频繁/太长时间的GC暂停 尝试减少应用程序的内存占用。 我们对此类问题的解决方案是建立在对对象图进行快照并从那里公开最耗费内存的数据结构的基础上的。 结果您将获得运行时透明性以了解JVM堆中实际发生的情况 以上是我们在监视我们自己的服务时发现的示例。 如我们所见在重大GC暂停后的某个时刻我们占据了70以上的旧一代。 老一代的高占用率通常会导致长时间的GC暂停因此Plumbr捕获了快照以显示其中的实际内容。 在这种特殊情况下我们发现包含ProbeDataProcessingTasks的处理队列的大小已增长到近1 GB。 了解应归咎于哪些数据结构使解决该问题变得微不足道。 结果GC暂停的频率和持续时间保持不变。 但是拍摄这些快照有些昂贵。 捕获快照所需的时间取决于堆中对象的数量以及它们之间的引用。 我们的代理商会仔细安排快照的时间以避免自己成为性能瓶颈。 综上所述在我们的基础架构中此特殊功能导致不可预测的内存快照流入。 更糟糕的是快照的大小也是不可预测的。 有时我们每小时可能只收到一个微小的快照然后突然间我们在很短的时间内被许多10 G快照轰炸 我们最初的解决方案存在问题 我们构建的第一个解决方案是专用的微服务用于处理快照的传入流。 我们立即开始面临问题。 首先我们还无法估算这些快照的大小。 最初配置的4G内存还远远不足以处理流向我们的较大快照。 要分析快照我们需要将对象图加载到内存中因此快照越大分析所需的RAM越多。 因此我们需要从亚马逊购买更大的计算机。 突然之间微服务不再是微服务了。 正如我们很快发现的那样在您的每月账单中实际上可以看到保持m4.10xlarge实例嗡嗡作响的24×7。 除了非常昂贵外机器有99的时间几乎处于空闲状态–发生的巨大堆快照很少见因此经常会超额配置10倍以上的机器来处理偶发的峰值。 此外分析持续时间很快就成为瓶颈。 快照需要花费10秒钟到数十分钟的时间来分析每个快照因此当在短时间内到达多个大型快照时队列等待时间成为一个问题 解决方案要求 了解了问题之后下一步就是将问题简化为解决方案的要求 分析任务不应在队列中等待数小时。 我们应该能够并行处理它们。 每当一个巨大的快照到达并且需要很长时间进行分析时其他快照就不应等待它完成。 对于每个快照我们可以估计执行分析将需要多少堆。 我们希望使用尽可能多的资源而不会过度配置基础架构。 对于以前建立过弹性环境的人来说解决方案的要求可能会很明显。 对于那些还没有的人我将在下一部分中介绍解决方案体系结构和实现的关键案例。 建立解决方案 这些要求有效地指示我们我们应该维护一个灵活的基础架构而不是一个单独的专用实例。 实例应按需生成实例类型应与接收到的快照的大小相对应。 因此我们继续将快照分析代码包装到docker容器中并利用AWS ECS将此类容器用作集群中的任务。 这样做之后我们偶然发现了第一个问题向外扩展并不像预期的那么琐碎。 仅仅为每个分析生成一个适当大小的新实例并在之后立即终止的天真的方法被证明是一个坏主意。 启动实例最多可能需要五分钟具体取决于实例类型。 此外AWS每小时执行一次计费因此使一个实例运行60分钟的成本要比运行十个实例每6分钟的成本便宜十倍。 在这种情况下典型的方法是使用AWS 自动扩展组。 显然这不适合我们因为AWS无法根据ECS任务所需的内存量自动生成实例。 您无法将任务提交给ECS集群除非该集群已经有足够的资源来容纳它。 我们的解决方案是根据分析任务所需的内存量将其划分为多个存储桶并为每个存储桶分配一个单独的群集。 收到新快照后我们检查目标集群是否有足够的可用资源来运行任务。 如果没有我们将在其自动扩展组中增加所需的实例数。 然后AWS自动启动一个具有适当大小的新实例。 因此从本质上讲我们最终得到了六个存储桶每个存储桶包含适当大小的实例可以根据需求进行扩展 第二个问题是通过扩展来解决自身问题。用于扩展的标准CloudWatch警报基于集群使用不足的情况。 如果集群闲置了足够长的时间我们会减少所需实例的数量。 “空闲”是根据群集中消耗的内存计算的如果在45分钟内内存使用率一直低于指定的阈值则立即扩展并终止额外的实例。 这里也有一个警告在自动伸缩组中进行伸缩时AWS选择一种特殊的方式来终止实例。 例如如果一个群集有两个实例其中一个实例处于空闲状态而另一个实例正在运行分析则完全有可能该活动实例将被杀死而不是空转一个实例。 扩展问题的解决方案是在分析期间我们为执行此扩展的特定实例设置了扩展保护 。 当我们开始分析时我们设置标志并在完成时将其删除。 自动缩放不会终止受保护而无法放大的实例。 最后一点就足够了从那以后我们就开始平稳运行。 找到了两个问题的解决方案我们得到了预期的结果。 更改后队列中等待的时间现在如下所示 带走 这是少数情况下的一种您可以提高应用程序的性能并减少容量需求以降低成本。 在大多数情况下您必须为提高性能付出很大的代价因此人们可以欣赏这些时刻。 现在按需计算比以往任何时候都容易因此也许您可以以类似的方式优化应用程序。 而且如果除了弹性基础架构的有趣案例之外该帖子还引发了人们对如何获得应用程序内存使用透明性的兴趣那就继续免费试用Plumbr试用一下。 翻译自: https://www.javacodegeeks.com/2016/05/elastic-infrastructure-practice.html
