做临时工有哪些网站,无锡企业网站改版,中国银行官网,网站做cdn服务流量java jvm调优这是以前的文章#xff08;第3部分#xff0c;共1部分#xff09;的继续#xff1a;有关性能调优#xff0c;Java中的JVM#xff0c;GC#xff0c;Mechanical Sympathy等的文章和视频的提要 。 事不宜迟#xff0c;让我们开始使用我们的下一组博客和视频第3部分共1部分的继续有关性能调优Java中的JVMGCMechanical Sympathy等的文章和视频的提要 。 事不宜迟让我们开始使用我们的下一组博客和视频斩……斩…… 这一次是Martin Thompson的博客文章和讨论。 马丁关于Java垃圾收集的第一篇文章基本上是精简了GC流程及其底层组件包括将光投向许多有趣的GC标志 -XX… 。 在他的下一次演讲中他讲述了机械同情人们正确相信的东西以及误解的神话。 在性能测试的讨论中Martin进一步完善了JavaOS和硬件的融合以展示对所有这些方面的理解如何有助于编写更好的程序。 Martin Thompson 标志太多无法调整GC以实现应用程序所需的吞吐量和延迟。 关于铃铛和口哨声的细节有很多文档但是没有文档可以指导您完成这些操作。 权衡 吞吐量 -XXGCTimeRatio 99 延迟 -XXMaxGCPauseMillis n 和内存 -Xmx n 是收集器所依赖的关键变量。 重要的是要注意热点通常无法实现上述目标。 如果低延迟应用程序在几秒钟内无响应则可能会造成灾难。 权衡取舍 为GC算法提供更多内存 可以通过包含活动集并减小堆大小来减少GC 通过管理堆和生成大小以及控制应用程序的对象分配率可以减少暂停的频率 可以通过同时运行GC来减少大暂停的频率 对象寿命 GC算法通常经过优化期望大多数对象的生存期很短而很少有对象生存期很长。 实验表明分代垃圾收集器支持的吞吐量要比非分代垃圾收集器好得多因此可以在服务器JVM中使用。 世界停止事件 为了使GC发生有必要使正在运行的应用程序的所有线程都必须暂停–垃圾收集器通过发出信号通知线程在到达安全点时停止的方式来暂停它们。 安全点时间是低延迟应用程序中的重要考虑因素除其他GC标志外还可以使用‑XX PrintGCApplicationStoppedTime标志来找到安全点时间。 当发生STW事件时随着线程从安全点释放时恢复系统将承受很大的调度压力因此 更少的 STW会使应用程序更高效。 热点堆组织 Java堆被划分为多个区域在伊甸园中创建了一个对象并将其移到幸存者空间并最终移交给了保有权。 PermGen用于存储运行时对象例如类和静态字符串。 收集器利用虚拟空间来满足吞吐量和延迟目标并调整区域大小以达到目标。 对象分配 TLAB线程本地分配缓冲区用于在Java中分配对象这比使用malloc便宜在大多数平台上需要10条指令。 次要收集的速率与对象分配的速率成正比。 大型对象 -XXPretenureSizeThreshold n 可能必须在Old Gen中分配但是如果阈值设置为低于TLAB大小则将不会在Old gen中创建它们-请注意不适用于G1 收集器 。 小型收藏 当Eden变满时将进行次要收集一旦对象变旧即超过阈值 -XXMaxTenuringThreshold 对象就会从eden提升到占位空间 。 在次要收集中将具有已知GC根的活动的可到达对象复制到幸存者空间。 热点使用卡片表维护跨代引用。 因此老一代的规模也是次要收藏成本的一个因素。 通过将Eden的大小调整为要提升的对象数可以提高收集效率。 这些很容易发生STW因此在最近时期成问题。 主要收藏 主要藏品收集了老一代以便可以推广年轻一代的物品。 收集器跟踪旧一代的填充阈值并在超过阈值时开始收集。 为避免升级失败您将需要调整旧版本允许容纳升级的填充 -XXPromotedPadding n 。 使用– Xms和-Xmx标志可以避免堆大小调整。 老一代的压缩会导致应用程序可能遇到的最大STW暂停之一并直接与老一代中的活动对象数量成比例。 通过调整幸存者空间的大小和占有阈值可以更慢地填补保有权空间但这又会导致更长的次要收集暂停时间这是由于幸存者空间之间的复制成本增加。 串行收集器 它是具有最小占用空间 -XX UseSerialGC 的最简单的收集器并且对次要和主要收集都使用单个线程。 并联收集器 有两种形式 -XX UseParallelGC 和 -XX UseParallelOld GC 对于次要集合使用多个线程对于主要集合使用单个线程-因为Java 7u4对这两种类型的集合都使用多个线程。 Parallel Old在多处理器系统上的性能非常好适用于批处理应用程序。 提供更多内存更大但更少的收集暂停可以帮助此收集器。 根据您的应用程序可以承受的暂停时间在Parallel Old和Concurrent收集器之间权衡一下在压缩旧一代后现代硬件上每GB实时数据的暂停时间应为1到5秒。 并发标记扫描CMS收集器 CMS -XX UseConcMarkSweepGC 收集器在旧版本中运行以收集在大型收集期间不再可访问的权属对象。 CMS不是压缩的收集器随着时间的推移会导致Old gen的碎片化。 当较大的对象无法放入Old gen时升级失败将触发FullGC。 CMS与您的应用程序一起运行会占用CPU时间。 如果CMS无法以足够的速度跟上升级的速度则可能会遭受“并发模式故障”。 垃圾优先G1收集器 G1 -XX UseG1GC 是Java 6中引入的新收集器现已在Java 7中得到正式支持。它是具有部分并发收集算法的分代收集器它以较小的STW增量暂停来压缩Old gen。 它将堆划分为可变大小的固定大小区域。 G1是由延迟驱动的目标驱动器 –XXMaxGCPauseMillis n 默认值 200ms。 在庞大的地区收集物品可能会非常昂贵。 它使用“记忆集”来跟踪对其他区域对象的引用。 记账和维护“记忆套”涉及很多成本。 与CMS类似G1可能会发生疏散失败空间溢出。 替代并行收集器 Oracle JRockit Real TimeIBM Websphere Real Time和Azul Zing是替代的并发收集器。 根据作者的说法Zing是唯一在收集压缩之间保持平衡的Java收集器并为所有世代保持高吞吐量。 无论堆大小如何在所有阶段包括次要回收期间Zing都是并行的。 对于所有针对延迟的并发收集器您必须放弃吞吐量并增加占用空间。 堆大小的预算至少为有效设置的活动集的2到3倍。 垃圾收集监控和调整 始终启用以收集最佳GC详细信息的重要标志 -verbose:gc
-Xloggc:filename
-XX:PrintGCDetails
-XX:PrintGCDateStamps
-XX:PrintTenuringDistribution
-XX:PrintGCApplicationConcurrentTime
-XX:PrintGCApplicationStoppedTime 使用Chewiebug JVisualVM之类的应用程序带有Visual GC插件来研究由于GC动作导致的应用程序行为。 运行可以重复执行的代表性负载测试随着您了解各种收集器继续尝试不同的配置直到达到吞吐量和延迟目标。 jHiccup帮助跟踪JVM中的暂停。 我们都知道要在等待时间要求高对象分配和提升率之间取得平衡这是一个艰巨的挑战有时选择商业解决方案来实现这一目标可能是一个更明智的想法。 结论 GC本身就是一个很大的主题它包含许多组件其中一些组件不断被替换因此重要的是要知道每个组件代表什么。 GC标志与其相关的组件同样重要并且了解它们以及如何使用它们也很重要。 启用某些标准GC标志来记录GC日志不会对JVM的性能产生任何重大影响。 只要您遵循作者的方法就可以使用第三方免费软件或商业工具。 —多次阅读该文章因为Martin涵盖了许多有关GC和收集器的细节需要仔细检查并充分理解。 - 马丁·汤普森Martin Thompson神话般的现代硬件获得“机械同情” 他将神话分为三类- 可能的 合理的和失败的 为了充分利用您拥有的硬件您需要了解硬件。 进行权衡改变旋钮这并不像您想的那样可怕。 好问题普通开发人员是否了解他们编程的硬件 还是不知道发生了什么事 还是我们有纪律并努力了解我们使用的平台 神话1 CPU并没有变得越来越快–时钟速度并不是决定性因素Sandy Bridge体系结构才是更快的品种。 6个端口支持并行性6个操作/周期。 Haswell有8个端口 代码除法运算的执行速度比任何其他算术运算都要慢。 CPU具有前端和后端周期。 随着我们更快地喂食它们它变得越来越快– 可能 神话2 内存为我们提供了随机访问权限 -CPU寄存器和缓冲区内部缓存L1L2L3和内存-分别以对这些区域的访问速度增加的顺序提到。 CPU一直在通过执行直接访问操作来降低其运行温度。 写比读少麻烦–缓冲区丢失代价高昂。 L1被组织成包含处理器将执行的代码的高速缓存行–通过没有高速缓存行未命中来提高效率。 预取程序有助于减少延迟并有助于读取流和可预测的数据。 TLB丢失也可以提高成本效益4K 内存页面大小。 简而言之由于底层硬件的工作方式读取内存并非接近随机读取而是逐次读取。 编写高度分支的代码可能会导致程序执行速度变慢–将具有凝聚力的内容放在一起是提高效率的关键。 – 破产 注意 TLAB和TLB是两个不同的概念 神话3 HDD提供了随机访问权限–旋转的磁盘和一条手臂在读取数据。 与内部轨道相比在外部轨道中放置的扇区更多区域位记录。 更快地旋转光盘并不是提高HDD性能的方法。 最小读写量为4K。 最佳光盘中的搜索时间为3-6毫秒笔记本电脑驱动器的速度较慢15毫秒。 旋转延迟需要一些时间。 数据传输需要100-220 MB /秒。 添加缓存可以改善将数据写入磁盘的能力而不能改善从磁盘读取数据的速度。 – 破产 神话4 SSD提供随机访问–读写很棒工作非常快一次4K。 删除与真正的删除不同它被标记为已删除而不是真正被删除-因为您无法以高分辨率擦除因此需要一次擦除整个块因此标记为已删除。 所有这些都会导致碎片因此需要进行GC和压缩。 读取是平滑的写入会受到碎片GC压缩等的阻碍也要注意写入放大。 使用SSD时有一些缺点但总体上还是不错的。 – 可能 我们能理解所有这些并编写更好的代码吗 结论不要仅仅因为一切都在表面上就把所有东西都视为理所当然而是在认为可能或合理之前尽可能自行检查检查和研究内部—为了编写好的代码并利用这些优点特征。 —很好地谈论和很好地报道了机械同情主题请观看视频以获取针对上述每个硬件组件收集的性能统计信息— Martin Thompson的 我们使用诸如“如何使用探查器”之类的东西。 或“如何使用调试器” 什么是性能 可能意味着两件事例如吞吐量或带宽可以通过多少和延迟系统响应的速度。 响应时间随我们在系统上施加更多负载而变化。 在设计任何系统之前我们需要性能要求即系统的吞吐量是多少或希望系统响应的速度延迟如何 您的系统是否可以随着业务进行经济扩展 开发人员时间昂贵硬件价格便宜 对于任何事情您都需要一个交易预算将系统要经历或要经历的不同组件和流程进行很好的分解。 我们如何进行性能测试 向系统施加负载看看吞吐量是上升还是下降 当我们施加负载时系统的响应时间是多少 压力测试不同于负载测试请参阅负载测试 压力测试 请参阅压力测试 是发生故障系统崩溃的一个点理想的系统将以一条平线继续。 同样重要的是不仅要从一个点执行负载测试而且要同时从多个点执行负载测试。 最重要的是高持续时间测试非常重要-这会给表面带来很多异常例如内存泄漏等。 建立测试套件是一个好主意这是由较小的部分组成的套件。 我们需要知道我们使用的系统的基本构建模块以及可以从中获得什么。 我们是否知道系统的不同阈值点及其组件可以处理多少 了解我们使用的算法知道如何测量它们并相应地使用它非常重要–使用真实数据进行反向操作。 我们什么时候应该测试性能 “过早的优化是万恶之源” – Donald Knuth /托尼·霍尔 优化是什么意思 知道并选择您的数据并围绕它进行工作以提高性能。 新的开发实践我们需要经常进行早期测试 从性能的角度来看“首先测试”实践非常重要然后逐渐设计系统因为将来更改可能会花费很多。 红色–绿色– 调试 – 配置文件 –重构这是一种“测试优先”性能方法的新方法而不是仅使用“红色-绿色重构”方法 反馈周期更早更短比将来发现问题要好。 如果您在Performance空间工作则使用“像实时”配对工作站一样Mac是一个不好的例子-linux机器是一个更好的选择。 性能测试可能会导致构建失败–并且它会导致CI系统中的构建失败 微型基准即卡尺应该是什么样 在代码中进行分割可能会非常昂贵请使用mask运算符 并发测试呢 仅仅是性能吗 不变式 争论 系统性能测试如何 我们是否应该能够测试不同范围的大型和小型客户。 了解您使用的系统的深入细节很有趣。 业务问题是解决的核心也是最重要的问题而不是讨论使用什么框架来构建它 。 请不要使用Java序列化因为它不是为在线协议设计的 使用观察者来衡量系统的性能而不是从系统内部来衡量它。 性能测试课程–很多技术知识和文化知识。 技术课–学习如何测量检查直方图 不要对系统进行采样当系统变得奇怪离群值等等时我们会漏掉一些东西–直方图有帮助 了解系统需要长时间的区域周围发生的事情很重要 从操作系统捕获时间也非常重要。 随着时间的流逝您将获得–准确性精度和分辨率大多数人将所有这些混合在一起。 在具有双插槽的机器上 时间可能不同步。 时间信息的质量在很大程度上取决于您所使用的操作系统。 在虚拟化系统上或者在两个不同的机器之间时间可能是个问题。 这个问题可以解决就是在两个系统之间来回操作注意启动和停止时钟时间然后将它们的一半来获得更准确的时间。 了解您的系统及其底层组件-获取指标并进行研究 使用像perstat这样的linux工具将在您的CPU和OS上提供大量与性能和统计相关的信息-分支预测和缓存丢失 RDTSC不是命令指令执行系统x86是命令指令系统并且操作不会以无序方式发生。 约束理论 –始终以数字1开头该数字会花费大部分时间–系统的瓶颈其余的问题序列可能取决于数字1而不是单独的问题 尝试创建绩效团队是一种反模式–让专家帮助将技能带给团队的其他成员并扩展他们的能力 提防YAGNI –关于进行性能测试–找借口 提交构建 3.40分钟令人担忧对于验收测试构建 15分钟降低团队信心。 测试环境应该等于生产环境 这些天容易获得完全相似的硬件 结论在编写依赖于低延迟的应用程序时从“测试优先”性能测试方法开始。 了解您的目标并朝着目标努力。 从硬件到开发环境全面了解您的底层系统。 在性能测试中不仅重要的技术问题文化的问题也同样重要。 在团队中共享和传播知识而不是将知识隔离给一两个人即所谓的团队专家。 每个人的责任不只是团队中的几个前辈。 了解有关跨各种硬件和操作系统以及系统之间的时间的更多信息。 由于查看所有此类视频和文章不切实际因此在下面的链接中提供了许多视频和文章以供进一步研究。 在许多情况下我已经解释或直接引用了作者为保留信息和希望传达的意思而不得不说的话。 有用的资源 您的GC日志在对您说话吗柯克·佩珀丁Kirk Pepperdine的G1GC版– 幻灯片 – 视频 表演特殊兴趣小组讨论 –由Richard Warburton主持 视频 缓存 RichardWarburto提供的“更有效地理解衡量和使用CPU缓存” 视频和幻灯片 Jonathan Corbet撰写的有关原子I / O操作Linux的文章 Gil Tene的有关Azul Zing低延迟GC和OpenJDK的文章和演示 视频和幻灯片 Martin Thompson的无锁算法实现终极性能 Performance Java用户小组–“面向希望将系统推向新高度的专业Java开发人员” 通过Kirk Pepperdine 调整线程池的大小 Gil Tene 如何不衡量延迟 理解Java垃圾收集及其处理方法作者Gil Tene Vanilla #Java了解Core Java的真正工作原理可以帮助您编写更简单更快的应用程序 作者Peter Lawrey 在生产中对Java进行性能分析 – Kaushik Srenevasan提供 Alexey Ragozin的HotSpot JVM垃圾回收选项备忘单v3 优化Google的仓库规模计算机NUMA体验 – Univ的作者。 CalSD和Google的资料 MegaPipe多位作者的可扩展网络I / O的新编程接口 每个程序员应该了解的关于内存的知识Ulrich Drepper 内存壁垒针对软件黑客的硬件视图 – Paul E. McKenneyLinux技术中心– IBM Beaverton 参考 第2部分共3部分 Java来历日历博客上来自JCG合作伙伴 Attila Mihaly Balazs的有关性能调优Java中的JVMGCMechanical Sympathy等的文章和视频的摘要 。 翻译自: https://www.javacodegeeks.com/2013/12/part-2-of-3-synopsis-of-articles-videos-on-performance-tuning-jvm-gc-in-java-mechanical-sympathy-et-al.htmljava jvm调优
