很多文章都是讲如何配置JVM各个参数的,但是生产环境里参数的值到底配置为多少,却没有一个具体的指标.文章分四个部分,分别是JVM说明.配置,GC的过程和具体配置值. 一.JVM空间说明 JDK 1.7及以前,Java 类信息.常量池.静态变量都存储在 Perm(永久代)里.类的元数据和静态变量在类加载的时候分配到 Perm,当类被卸载的时候垃圾收集器从 Perm 处理掉. JDK 1.8 的对 JVM 架构的改造将类元数据放到本地内存中,另外,将常量池和静态变量放到 Java 堆里.HotSop

OOM这个缩写就是Java程序开发过程中让人最头痛的问题:Out of Memory.在很多开发人员的开发过程中,或多或少的都会遇到这类问题,这类问题定位比较困难,往往需要根据经验来判断可能出现问题的代码.原因主要是两个:对象没有被释放(多种情况引起,往往是比较隐蔽的引用导致被Hold而无法被回收).另一种就是真的Memory不够用了,需要增加JVM的Heap来满足应用程序的需求.最近有同事发的关于解决OOM的问题,让我了解了原来OOM除了在JVM Heap不够时会发生,在Native Heap

这些选项是特定于Java HotSpot虚拟机的通用选项.-X 显示所有可用-X选项的帮助. -Xbatch 禁用后台编译.默认情况下,JVM将该方法编译为后台任务,以解释器模式运行该方法,直到后台编译完成.该-Xbatch标志禁用后台编译,以便所有方法的编译作为前台任务继续进行,直到完成. 此选项相当于-XX:-BackgroundCompilation. -Xbootclasspath:path 指定以冒号(:)分隔的目录,JAR文件和ZIP存档的列表,以搜索引导类文件.这些用于代替JDK中

上周公司有一个应用,一到晚上高峰期的时候RT(响应时间)就很长.后来上服务器看了下JVM的配置,发现运维在启动参数那里把-Xss给设成了10M.导致每个线程占用的内存过大,导致内存消耗过快,其它线程排队等待的情况.后来把-Xss改成1M之后,系统性能有明显的提高. 总结: 1.-Xss参数不可以设的过大,特别在一些高并发场景的系统下.(低并发的话,没关系) 2.JVM的参数不要任由运维去配.运维使用的参数可能不符合当前系统的业务场景.还需要开发人员去优化

原文地址:https://blog.csdn.net/xingkongtianma01/article/details/80689928 大 多数情况下,我们并不需要关心JVM的底层,但是如果了解它的话,对于我们系统调优是非常有用的,在这里面了解JVM的GC原理,是非常重要的一块知识. 我们都知道对于一个大型网站,如果JVM频繁发生FULL GC,那么将会是致命的危险,不仅仅会造成网站响应迟钝,更严重的时候会导致系统崩溃,这对用户体验来讲,都是我们不愿意看到的. 在JVM里的内存空间,从大的层面

一.Tomcat配置优化 1.Tomcat配置调优 主要调优内容 增加最大连接数 调整工作模式 启用gzip压缩 调整JVM内存大小 作为Web时,动静分离 合理选择垃圾回收算法 尽量使用较新JDK版本 <Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="1000" minSpareThreads="100&q

勿在流沙住高台,出来混迟早要还的. 做一个积极的人 编码.改bug.提升自己 我有一个乐园,面向编程,春暖花开! 上一篇分享了JVM及其启动流程,今天介绍一下JVM内部的一些区域,以及具体的区域在运行过程中会发生哪些异内存常! 其实也就对应了内存管理的第一篇中 JVM的第三个阶段,程序运行内存溢出. 知识地图: 一.概述 Java的内存管理采用[自动内存管理]机制,因为这个自动管理机制,Java程序员就不需要去写释放内存的代码,而且不容易出现内存泄漏问题(比C/C++程序员少一些烦恼).但是由于

 基于jdk7和jdk8分析 JVM的内存区域 目录前言1.什么是JVM2.JRE/JDK/JVM是什么关系3.JVM执行程序的过程4. JVM的生命周期5.JVM垃圾回收一.运行时数据区的组成1.程序计数器2.Java栈(虚拟机栈)1).局部变量表2).操作数栈3).指向运行时常量池的引用4).方法返回地址3.本地方法栈4.堆5.方法区 直接内存(Direct Memory)二.对象实例化分析三.内存溢出简单测试方法1.虚拟机栈溢出2.堆溢出3.PermGen(永久代)异常四.Metaspac

下载官方的tomcat,我这里用的是TOMCAT 8.5.46,然后解压出来,解压后的目录如下图 一.server.xml配置优化 进入conf目录,打开server.xml 文件 1. 找到 <Executor name="tomcatThreadPool" .../>,将其修改如下 <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads

1. Java内存区域 1.1 运行时数据区 Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域.主要包括:程序计数器.虚拟机栈.本地方法栈.Java堆.方法区(运 行时常量池).直接内存. 程序计数器 程序计数器(Program Counter Register)是一块较小的内存空间,可以看作是当前线程所执行的字节码的行号指示器.在虚拟机概念模型中,字节码解释器工作时就是通过改变计数器的值来选取下一条需要执行的字节码指令,分支.循环.跳转.异常处理.线程恢复等

下载地址:http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#jdk-7u80-oth-JPR 推荐方式A: vi .bash_profile 输入以下内容 然后执行source .bash_profile生效新配置 # Mac默认 JDK 6(Mac默认自带了一个jdk6版本) export JAVA_6_HOME=`/usr/libexec/jav

目录 前言 多表配置优化 自定义实体 杂谈 结语 前言   最近利用零碎的时间对代码生成器做了进一步更新:优化多表配置模块,增加自定义实体功能,美化单表和多表配置的UI界面,修复用户反馈的若干bug,一起看一下吧! 多表配置优化   新版多表配置模块使用了多模块生成模式,每个模块下可以配置不同的方法,并且摒弃了原来的Map参数类型,参数和返回值全部使用entity,虽然牺牲了一定的灵活程度,但总体来说,利大于弊.如果自己做个小项目倒无所谓,倘若多人协作开发,Map满天飞,那种绝望只有经历过的人才

为更好的适应JAVA技术的发展,使用更先进及前沿的技术.所以推出将我们现在使用的JDK1.6(1.7)及tomcat6(7)升级至JDK1.8及tomcat8,使我们的系统获得更好的性能,更好适应未来及节约成本 一.升级JDK8流程 1.服务器JDK版本升级 将JDK1.8版本安装到服务器上 2.老系统升级时专用流程 将老代码(1.6或1.7编译的)部署到升级的服务器上(JDK有向下兼容原则),灰度观察一段时间(但也有部分不兼容的内容)查看代码运行是否有问题 JDK不向下兼容部分: https:

yarn-site.xml <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>22528</value> <discription>每个节点可用内存,单位MB,默认9182MB</discription> </property> <property> <name>yarn.scheduler.minimu

很多程序员在解决JVM性能问题的时候,花开了很多时间去调优应用程序级别的性能瓶颈,当你读完这本系列文章之后你会发现我可能更加系统地看待这类的问题.我说过JVM的自身技术限制了Java企业级应用的伸缩性.首先我们先列举一些主导因素. 主流的硬件服务器提供了大量的内存 分布式系统有大量内存的需求,而且该需求在持续增长 一个普通Java应用程序所持有的对空间大概在1GB~4GB,这远远低于一个硬件服务器的内存管理能力以及一个分布式应用程序的内存需求量.这被称之为Java内存墙,如下图所示(图中表述Ja

一.HotSpot JVM 提供了三类参数 现在的JVM运行Java程序(和其它的兼容性语言)时在高效性和稳定性方面做的非常出色.例如:自适应内存管理.垃圾收集.及时编译.动态类加载.锁优化等.虽然有了这种程度的自动化(或者说有这么多自动化),但是JVM仍然提供了足够多的外部监控和手动调优工具(允许命令行参数可以在JVM启动时传入到JVM中).在有错误或低性能的情况下,JVM必须能够让调试,JVM提供了几百个这样的参数,所以如果没有这方面的知识很容易迷失. 1)第一类包括了标准参数.顾名思义,标

 jvm性能优化及内存分区 2012-09-17 15:51:37 分类: Java Some of the default values for Sun JVMs are listed below. JDK 1.3.1_06 Initial Size Maximum Size Client JVM 1MB 32MB Server JVM 1MB 64MB JDK 1.4.1_01 Initial Size Maximum Size Client JVM 4MB 64MB Server JVM

常用JVM配置参数 常用JVM配置参数主要有:Trace跟踪参数.堆的分配参数.栈的分配参数. 一.Trace跟踪参数 跟踪参数用于跟踪监控JVM,对于开发人员来讲用于JVM调优以及故障排查的. 1.打印GC的简要信息 -verbose:gc -XX:+PrintGC 这两个配置参数效果是一样的,都是在发生GC时打印出简要的信息,例如执行代码 public static void main(String[] args) { byte[] bytes = null; for (int i = 0;

java性能优化权威指南读后笔记 三重境界 1.花似雾中看:对于遇到的额问题还看不清,不知道真真假假,是是非非. 2.悠然见南山:虽然刚开始对这个领域还不清楚,但随着时间推移,你对它有许多自己的见解,但对重要的知识还缺乏理解. 3.一览众山小:你对这个领域已经很熟悉了,能够游刃有余的解决遇到的问题. 三大步骤 1.性能监控 1.JVM性能监控: 1.监控垃圾收集报告(GC日志) 2.监控JIT编译器 3.监控内加载 2.依据: 1.GC日志 2.堆转储快照 3.线程快照 4.异常堆栈 2.性能分

Tomcat 本身与 JVM 优化 Tomcat:调整Server.xml JVM:bat启动服务方式的话修改catalina.bat 服务式启动的话参考:http://www.cnblogs.com/qlqwjy/p/8007490.html Tomcat 的缺省配置是不能稳定长期运行的,也就是不适合生产环境,它会死机,让你不断重新启动,甚至在午夜时分唤醒你.对于操作系统优化来说,是尽可能的增大可使 用的内存容量.提高CPU 的频率,保证文件系统的读写速率等.经过压力测试验证,在并发连接很多的

  Tomcat 的缺省配置是不能稳定长期运行的,也就是不适合生产环境,它会死机,让你不断重新启动,甚至在午夜时分唤醒你.对于操作系统优化来说,是尽可能的增大可使用的内存容量.提高CPU 的频率,保证文件系统的读写速率等.经过压力测试验证,在并发连接很多的情况下,CPU 的处理能力越强,系统运行速度越快. Tomcat 的优化不像其它软件那样,简简单单的修改几个参数就可以了,它的优化主要有三方面,分为系统优化,Tomcat 本身的优化,Java 虚拟机(JVM)调优.系统优化就不在介绍了,接下来