- 浏览: 194114 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (391)
- java (18)
- python (3)
- ruby (4)
- linux (48)
- 网络 (9)
- 前端 (2)
- 社会、文化、哲学、人生、百态 (0)
- 工具 (10)
- 下载 (0)
- 常用地址 (0)
- tracert (0)
- mysql (8)
- 开源相关收藏 (1)
- 模块查看依懒 (1)
- watch使用 (1)
- Tcpdump (2)
- easy_install安装 (1)
- 构造redis批量删除脚本 (1)
- MYSQL 性能测试 (1)
- JAVA code encode utf-8 (1)
- linux nginx awk 实时 每妙 (1)
- mkpasswd (1)
- spring security oauth (1)
- jmap dump java memory Analyzer (1)
- JAVA DUMP (1)
- swap linux 过高 解决 (1)
- SWAP (1)
- jmap jstat jstack dump (1)
- java jconsole 的使用 (1)
- git 常用 (1)
- MYSQL 索引 动态 唯一 (1)
- TCP 三次握手 四次挥手 (1)
- linux date (1)
- 删除 空行 注释行 (1)
- maven3 yum linux install repository (1)
- linux git 搭建 (1)
- linux sar eth1 查看 流量 (1)
- sar (1)
- netstat ip 过滤 常用脚本 (1)
- Tcpdump 包分析网络连接过程 (1)
- net ipv4 tcp time wait tw recycle (0)
- /etc/sysctl.conf linux 网络 配置 (1)
- ss 网络连接查看 (比netstat 快很多,实时性牺牲) (1)
- MYSQL 关键字 (1)
- Linux 下多核CPU知识 (1)
- top (1)
- 令牌 证书 (1)
- mysql unix timestamp (1)
- 端口扫描 nc nmap (1)
- 204 http code 状态码 (1)
- ss -s ss -l (1)
- linux 常用 curl (1)
- linux sed 替换 换行 (1)
- centos yum install rpm install (1)
- spring-mvc源码解读 (1)
- 使用iftop查看实时的网络流量 (0)
- linux 命令 expect (1)
- HTTP (1)
- openssl ddif 加密 (1)
- iptables 详解 (1)
- python 虚拟化 VirtualEnv virtualenvwrapper (1)
- nginx (2)
- more less 实用技巧 (1)
- linux nginx (2)
- linux curl https ssl 证书 ca (1)
- openssl (1)
- php mysql linux (1)
- linux 虚拟机 虚拟 xen (0)
- linux 虚拟机 虚拟 xen kvm (1)
- linux perl 单行执行技巧 (1)
- mysql 查看库占用空间 表查用空间 (1)
- linux tcpdump (1)
- maven (1)
- sun.misc.Unsafe (1)
- OpenSSL生成证书 (1)
- http://blog.csdn.net/zzulp/article/details/8018751 (1)
- maven 本地 jar dependency (1)
- 计算JAVA代码行数最简单命令 sed (1)
- 常用的证书格式转换 rsa eg (1)
- 加密 解密 签名 (1)
- 分析jar包冲突 (1)
- 使用JMockit编写java单元测试 (1)
- Linux 技巧:让进程在后台可靠运行的几种方法 (1)
- 环境变量控制 (1)
- 5+ 个 tar 命令的用法,附示例 (1)
- scp自动输入密码 (1)
- ps axo pid (1)
- ppid (1)
- comm (1)
- pmem (1)
- lstart|grep mysql (0)
- lstart (1)
- etime|grep mysql (1)
- UML类图字少好理解 (1)
- HTTP经典文章 (1)
- git (1)
- Git常用命令 (1)
- LINUX 系统被攻击的分析过程 (1)
- NIO (1)
- LINUX 操作快捷键使用 (1)
- openSSL命令、PKI、CA、SSL证书原理 (1)
- shell (2)
- 转载 (1)
- mysqldump 可以直接dump->xml (1)
- VIM比较全面的文章 (1)
- eclipse regex 正则表达式 (1)
- synchronized (1)
- 锁 (1)
- java 正则表达式 regex (1)
- Reference Queue 引用 源码 (1)
- spring aop 源码 分析 (1)
- java @Cache @Transaction 注解 (1)
- spring aop (1)
- spring jdk proxy cglib 动态代理 性能比较 (1)
- spring proxy private public 代理限制 (1)
- spring transaction aop 事务 (1)
- spring autowire 注解注入 (1)
- 桥接 NAT NAT地址转换 内部网络 虚拟网络 (1)
- spring-web-mvc 源码解读 之 RequestMappingHandlerMapping (1)
- find atime mtime ctime -n n +n (1)
- android studio 快捷键初探 (1)
- android 源码阅读的计划 (1)
- 计算机网络学习-VLAN (1)
- sed 高级 合并行 (1)
- CAP 一致性 可用性 分布式容错性 (1)
- android lib so 库文件 (0)
- android lib so 库文件 移植 (1)
- android 不错的博文 (1)
- sourceinsight 源码 阅读 (1)
- Android Tab UI (1)
- 诗 (1)
- mysql 批处理 (0)
- netty 堆外内存 DirectByteBuffer (1)
- netty 并发 百万 推送 (1)
- Linux操作系统中内存buffer和cache的区别 (1)
- maven intellij target bytecode version (1)
- linux sleep()的实现原理 (1)
- android (2)
- javadoc 代码注释规范 (1)
- spring 自动注入bean auto (1)
- Photoshop CS6常用快捷键 (1)
- 股票 数据 机器 分析 (1)
- 批处理 (1)
- mysql -e (1)
- char (1)
- Unicode (1)
- 编码 (1)
- utf8 (1)
- utf-8 (1)
- utf16 (1)
- utf-16 (1)
- IntelliJ IDEA (1)
- ide (1)
- idea (1)
- intellij (1)
- 文件 (1)
- 目录 (1)
- 源代码 (1)
- CountDownLatch (1)
- CyclicBarrier (1)
- Semaphore (1)
- spring (1)
- linux 查看不同进制文件 (1)
- WebMvcConfigurationSupport (1)
- sdkman工具的使用 (1)
- http header (1)
- LINUX系统优化 (1)
最新评论
-
gelongmei:
威武我大酒神
shell脚本不换行刷新数据
CMS gc实践总结
http://blog.csdn.net/turkeyzhou/article/details/5998869
声明:原文转自http://www.blogjava.net/killme2008/archive/2009/09/22/295931.html,该文所有合法权益归原作者所有,仅在此做技术分享使用。
首先感谢阿宝同学的帮助,我才对这个gc算法的调整有了一定的认识,而不是停留在过去仅仅了解的阶段。在读过sun的文档和跟阿宝讨论之后,做个小小的总结。
CMS,全称Concurrent Low Pause Collector,是jdk1.4后期版本开始引入的新gc算法,在jdk5和jdk6中得到了进一步改进,它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求,能够承受垃圾回收线程和应用线程共享处理器资源,并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收,也就是年老代的回收,目标是尽量减少应用的暂停时间,减少full gc发生的几率,利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中,因为有缓存的存在,并且对于响应时间也有比较高的要求,因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器,以便获得更短的垃圾回收的暂停时间,提高程序的响应性。
CMS并非没有暂停,而是用两次短暂停来替代串行标记整理算法的长暂停,它的收集周期是这样:
初始标记(CMS-initial-mark) -> 并发标记(CMS-concurrent-mark) -> 重新标记(CMS-remark) -> 并发清除(CMS-concurrent-sweep) ->并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。
其中的1,3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象,这个阶段称为初始标记;第二次暂停是在并发标记之后,暂停所有应用程序线程,重新标记并发标记阶段遗漏的对象(在并发标记阶段结束后对象状态的更新导致)。第一次暂停会比较短,第二次暂停通常会比较长,并且remark这个阶段可以并行标记。
而并发标记、并发清除、并发重设阶段的所谓并发,是指一个或者多个垃圾回收线程和应用程序线程并发地运行,垃圾回收线程不会暂停应用程序的执行,如果你有多于一个处理器,那么并发收集线程将与应用线程在不同的处理器上运行,显然,这样的开销就是会降低应用的吞吐量。Remark阶段的并行,是指暂停了所有应用程序后,启动一定数目的垃圾回收进程进行并行标记,此时的应用线程是暂停的。
CMS的young generation的回收采用的仍然是并行复制收集器,这个跟Paralle gc算法是一致的。
下面是参数介绍和遇到的问题总结,
1、启用CMS:-XX:+UseConcMarkSweepGC。 咳咳,这里犯过一个低级错误,竟然将+号写成了-号
2。CMS默认启动的回收线程数目是 (ParallelGCThreads + 3)/4) ,如果你需要明确设定,可以通过-XX:ParallelCMSThreads=20来设定,其中ParallelGCThreads是年轻代的并行收集线程数
3、CMS是不会整理堆碎片的,因此为了防止堆碎片引起full gc,通过会开启CMS阶段进行合并碎片选项:-XX:+UseCMSCompactAtFullCollection,开启这个选项一定程度上会影响性能,阿宝的blog里说也许可以通过配置适当的CMSFullGCsBeforeCompaction来调整性能,未实践。
4.为了减少第二次暂停的时间,开启并行remark: -XX:+CMSParallelRemarkEnabled,如果remark还是过长的话,可以开启-XX:+CMSScavengeBeforeRemark选项,强制remark之前开始一次minor gc,减少remark的暂停时间,但是在remark之后也将立即开始又一次minor gc。
5.为了避免Perm区满引起的full gc,建议开启CMS回收Perm区选项:
+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
6.默认CMS是在tenured generation沾满68%的时候开始进行CMS收集,如果你的年老代增长不是那么快,并且希望降低CMS次数的话,可以适当调高此值:
-XX:CMSInitiatingOccupancyFraction=80
这里修改成80%沾满的时候才开始CMS回收。
7.年轻代的并行收集线程数默认是(ncpus <= ? ncpus : 3 + ((ncpus * 5) /,如果你希望设定这个线程数,可以通过-XX:ParallelGCThreads= N 来调整。
8.进入重点,在初步设置了一些参数后,例如:
-server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=64m
-XX:MaxPermSize=64m -XX:-UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled
-XX:SoftRefLRUPolicyMSPerMB=0
需要在生产环境或者压测环境中测量这些参数下系统的表现,这时候需要打开GC日志查看具体的信息,因此加上参数:
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/home/test/logs/gc.log
在运行相当长一段时间内查看CMS的表现情况,CMS的日志输出类似这样:
4391.322: [GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user=0.02 sys=0.02, real=0.03 secs]
4391.352: [CMS-concurrent-mark-start]
4391.779: [CMS-concurrent-mark: 0.427/0.427 secs] [Times: user=1.24 sys=0.31, real=0.42 secs]
4391.779: [CMS-concurrent-preclean-start]
4391.821: [CMS-concurrent-preclean: 0.040/0.042 secs] [Times: user=0.13 sys=0.03, real=0.05 secs]
4391.821: [CMS-concurrent-abortable-preclean-start]
4392.511: [CMS-concurrent-abortable-preclean: 0.349/0.690 secs] [Times: user=2.02 sys=0.51, real=0.69 secs]
4392.516: [GC[YG occupancy: 111001 K (235968 K)]4392.516: [Rescan (parallel) , 0.0309960 secs]4392.547: [weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user=0.17 sys=0.00, real=0.09 secs]
4392.609: [CMS-concurrent-sweep-start]
4394.310: [CMS-concurrent-sweep: 1.595/1.701 secs] [Times: user=4.78 sys=1.05, real=1.70 secs]
4394.310: [CMS-concurrent-reset-start]
4394.364: [CMS-concurrent-reset: 0.054/0.054 secs] [Times: user=0.14 sys=0.06, real=0.06 secs]
其中可以看到CMS-initial-mark阶段暂停了0.0303050秒,而CMS-remark阶段暂停了0.0932010秒,因此两次暂停的总共时间是0.123506秒,也就是123毫秒左右。两次短暂停的时间之和在200以下可以称为正常现象。
但是你很可能遇到两种fail引起full gc:Prommotion failed和Concurrent mode failed。
Prommotion failed的日志输出大概是这样:
[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K(
2166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]
这个问题的产生是由于救助空间不够,从而向年老代转移对象,年老代没有足够的空间来容纳这些对象,导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向:增大救助空间、增大年老代或者去掉救助空间。增大救助空间就是调整-XX:SurvivorRatio参数,这个参数是Eden区和Survivor区的大小比值,默认是32,也就是说Eden区是Survivor区的32倍大小,要注意Survivo是有两个区的,因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor区,让对象尽量在survitor区呆长一点,减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代,加快年老代的回收频率,减少年老代暴涨的可能性,这个是通过将-XX:SurvivorRatio 设置成比较大的值(比如65536)来做到。在我们的应用中,将young generation设置成256M,这个值相对来说比较大了,而救助空间设置成默认大小(1/34),从压测情况来看,没有出现prommotion failed的现象,年轻代比较大,从GC日志来看,minor gc的时间也在5-20毫秒内,还可以接受,因此暂不调整。
Concurrent mode failed的产生是由于CMS回收年老代的速度太慢,导致年老代在CMS完成前就被沾满,引起full gc,避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值,让CMS更早更频繁的触发,降低年老代被沾满的可能。我们的应用暂时负载比较低,在生产环境上年老代的增长非常缓慢,因此暂时设置此参数为80。在压测环境下,这个参数的表现还可以,没有出现过Concurrent mode failed。
参考资料:
《JDK5.0垃圾收集优化之--Don't Pause》 by 江南白衣
《记一次Java GC调整经历》1,2 by Arbow
Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
Tuning Garbage Collection with the 5.0 JavaTM Virtual Machine
声明:原文转自http://www.blogjava.net/killme2008/archive/2009/09/22/295931.html,该文所有合法权益归原作者所有,仅在此做技术分享使用。
首先感谢阿宝同学的帮助,我才对这个gc算法的调整有了一定的认识,而不是停留在过去仅仅了解的阶段。在读过sun的文档和跟阿宝讨论之后,做个小小的总结。
CMS,全称Concurrent Low Pause Collector,是jdk1.4后期版本开始引入的新gc算法,在jdk5和jdk6中得到了进一步改进,它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求,能够承受垃圾回收线程和应用线程共享处理器资源,并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收,也就是年老代的回收,目标是尽量减少应用的暂停时间,减少full gc发生的几率,利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中,因为有缓存的存在,并且对于响应时间也有比较高的要求,因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器,以便获得更短的垃圾回收的暂停时间,提高程序的响应性。
CMS并非没有暂停,而是用两次短暂停来替代串行标记整理算法的长暂停,它的收集周期是这样:
初始标记(CMS-initial-mark) -> 并发标记(CMS-concurrent-mark) -> 重新标记(CMS-remark) -> 并发清除(CMS-concurrent-sweep) ->并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。
其中的1,3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象,这个阶段称为初始标记;第二次暂停是在并发标记之后,暂停所有应用程序线程,重新标记并发标记阶段遗漏的对象(在并发标记阶段结束后对象状态的更新导致)。第一次暂停会比较短,第二次暂停通常会比较长,并且remark这个阶段可以并行标记。
而并发标记、并发清除、并发重设阶段的所谓并发,是指一个或者多个垃圾回收线程和应用程序线程并发地运行,垃圾回收线程不会暂停应用程序的执行,如果你有多于一个处理器,那么并发收集线程将与应用线程在不同的处理器上运行,显然,这样的开销就是会降低应用的吞吐量。Remark阶段的并行,是指暂停了所有应用程序后,启动一定数目的垃圾回收进程进行并行标记,此时的应用线程是暂停的。
CMS的young generation的回收采用的仍然是并行复制收集器,这个跟Paralle gc算法是一致的。
下面是参数介绍和遇到的问题总结,
1、启用CMS:-XX:+UseConcMarkSweepGC。 咳咳,这里犯过一个低级错误,竟然将+号写成了-号
2。CMS默认启动的回收线程数目是 (ParallelGCThreads + 3)/4) ,如果你需要明确设定,可以通过-XX:ParallelCMSThreads=20来设定,其中ParallelGCThreads是年轻代的并行收集线程数
3、CMS是不会整理堆碎片的,因此为了防止堆碎片引起full gc,通过会开启CMS阶段进行合并碎片选项:-XX:+UseCMSCompactAtFullCollection,开启这个选项一定程度上会影响性能,阿宝的blog里说也许可以通过配置适当的CMSFullGCsBeforeCompaction来调整性能,未实践。
4.为了减少第二次暂停的时间,开启并行remark: -XX:+CMSParallelRemarkEnabled,如果remark还是过长的话,可以开启-XX:+CMSScavengeBeforeRemark选项,强制remark之前开始一次minor gc,减少remark的暂停时间,但是在remark之后也将立即开始又一次minor gc。
5.为了避免Perm区满引起的full gc,建议开启CMS回收Perm区选项:
+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
6.默认CMS是在tenured generation沾满68%的时候开始进行CMS收集,如果你的年老代增长不是那么快,并且希望降低CMS次数的话,可以适当调高此值:
-XX:CMSInitiatingOccupancyFraction=80
这里修改成80%沾满的时候才开始CMS回收。
7.年轻代的并行收集线程数默认是(ncpus <= ? ncpus : 3 + ((ncpus * 5) /,如果你希望设定这个线程数,可以通过-XX:ParallelGCThreads= N 来调整。
8.进入重点,在初步设置了一些参数后,例如:
-server -Xms1536m -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=64m
-XX:MaxPermSize=64m -XX:-UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled
-XX:SoftRefLRUPolicyMSPerMB=0
需要在生产环境或者压测环境中测量这些参数下系统的表现,这时候需要打开GC日志查看具体的信息,因此加上参数:
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/home/test/logs/gc.log
在运行相当长一段时间内查看CMS的表现情况,CMS的日志输出类似这样:
4391.322: [GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user=0.02 sys=0.02, real=0.03 secs]
4391.352: [CMS-concurrent-mark-start]
4391.779: [CMS-concurrent-mark: 0.427/0.427 secs] [Times: user=1.24 sys=0.31, real=0.42 secs]
4391.779: [CMS-concurrent-preclean-start]
4391.821: [CMS-concurrent-preclean: 0.040/0.042 secs] [Times: user=0.13 sys=0.03, real=0.05 secs]
4391.821: [CMS-concurrent-abortable-preclean-start]
4392.511: [CMS-concurrent-abortable-preclean: 0.349/0.690 secs] [Times: user=2.02 sys=0.51, real=0.69 secs]
4392.516: [GC[YG occupancy: 111001 K (235968 K)]4392.516: [Rescan (parallel) , 0.0309960 secs]4392.547: [weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user=0.17 sys=0.00, real=0.09 secs]
4392.609: [CMS-concurrent-sweep-start]
4394.310: [CMS-concurrent-sweep: 1.595/1.701 secs] [Times: user=4.78 sys=1.05, real=1.70 secs]
4394.310: [CMS-concurrent-reset-start]
4394.364: [CMS-concurrent-reset: 0.054/0.054 secs] [Times: user=0.14 sys=0.06, real=0.06 secs]
其中可以看到CMS-initial-mark阶段暂停了0.0303050秒,而CMS-remark阶段暂停了0.0932010秒,因此两次暂停的总共时间是0.123506秒,也就是123毫秒左右。两次短暂停的时间之和在200以下可以称为正常现象。
但是你很可能遇到两种fail引起full gc:Prommotion failed和Concurrent mode failed。
Prommotion failed的日志输出大概是这样:
[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K(
2166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]
这个问题的产生是由于救助空间不够,从而向年老代转移对象,年老代没有足够的空间来容纳这些对象,导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向:增大救助空间、增大年老代或者去掉救助空间。增大救助空间就是调整-XX:SurvivorRatio参数,这个参数是Eden区和Survivor区的大小比值,默认是32,也就是说Eden区是Survivor区的32倍大小,要注意Survivo是有两个区的,因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor区,让对象尽量在survitor区呆长一点,减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代,加快年老代的回收频率,减少年老代暴涨的可能性,这个是通过将-XX:SurvivorRatio 设置成比较大的值(比如65536)来做到。在我们的应用中,将young generation设置成256M,这个值相对来说比较大了,而救助空间设置成默认大小(1/34),从压测情况来看,没有出现prommotion failed的现象,年轻代比较大,从GC日志来看,minor gc的时间也在5-20毫秒内,还可以接受,因此暂不调整。
Concurrent mode failed的产生是由于CMS回收年老代的速度太慢,导致年老代在CMS完成前就被沾满,引起full gc,避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值,让CMS更早更频繁的触发,降低年老代被沾满的可能。我们的应用暂时负载比较低,在生产环境上年老代的增长非常缓慢,因此暂时设置此参数为80。在压测环境下,这个参数的表现还可以,没有出现过Concurrent mode failed。
参考资料:
《JDK5.0垃圾收集优化之--Don't Pause》 by 江南白衣
《记一次Java GC调整经历》1,2 by Arbow
Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
Tuning Garbage Collection with the 5.0 JavaTM Virtual Machine
相关推荐
GChisto及CMS GC相应补丁文件,补丁文件未亲测。 This patch adds the following features and improvements when using CMS GC in incremental mode: detecting Full GCs corrected parsing errors when using -XX:...
《工作手册式CMS建站项目实践》任务书任务4-搭建企业网站开发环境.pdf《工作手册式CMS建站项目实践》任务书任务4-搭建企业网站开发环境.pdf《工作手册式CMS建站项目实践》任务书任务4-搭建企业网站开发环境.pdf...
毕业综合实践报告实例网站CMS开发实践.doc
【现象】悲催的是运行了几天后,突然有几台机器开始报警,上机器看到的现象是CMS GC的remark竟然花了20s+,而实际上这个时候old也就用了2g+,这个时
cms总结文档,cms总结文档cms总结文档cms总结文档cms总结文档,cms总结文档
《工作手册式CMS建站项目实践》任务书任务12-维护企业网站.pdf《工作手册式CMS建站项目实践》任务书任务12-维护企业网站.pdf《工作手册式CMS建站项目实践》任务书任务12-维护企业网站.pdf《工作手册式CMS建站项目...
《工作手册式CMS建站项目实践》任务书任务11-验收企业网站.pdf《工作手册式CMS建站项目实践》任务书任务11-验收企业网站.pdf《工作手册式CMS建站项目实践》任务书任务11-验收企业网站.pdf《工作手册式CMS建站项目...
《工作手册式CMS建站项目实践》任务书任务2-设计企业网站前台版面.pdf《工作手册式CMS建站项目实践》任务书任务2-设计企业网站前台版面.pdf《工作手册式CMS建站项目实践》任务书任务2-设计企业网站前台版面.pdf...
用于分析 java gc日志文件。根据日志中的CMS GC统计信息可得到Full GC(也可以理解为Major GC)以及Minor GC相关数据
动易cms动易cms动易cms动易cms动易cms动易cms动易cms动易cms动易cms动易cms动易cms动易cms
cms源码 cms源码 cms源码 cms源码 cms源码 cms源码 cms源码 cms源码
51javacms是一款纯ajax的mvc架构cms;摒弃了传统的ssh的java企业级架构的庞大和臃肿;代码简洁,功能简单实用,安装一键式;站内搜索是使用lucene3.3的技术;真正的开源;真正的免费;非常适合互联网中小型网站的...
苹果cms在线采集70多个接口,用谷歌浏览器用谷歌浏览器
jvm性能调优-垃圾收集器parnew&CMS底层三色标记算-performance-gc-parnew-cms
基于thinkphp的cms学生学籍管理系统 功能模块:1.管理员模块 管理学生和用户(班主任和年级主任) 2.教师模块 对学生进行增删改 对自己密码修改 操作步骤: 1.首先将数据库相关操作完成 建立数据库连接 数据表的...
企业CMS源码,企业CMS源码,企业CMS源码.
aspcms企业网站建设开源程序,对于一些不懂开发的人员来说,是一款不错的软件AspCms2.0.1
CMS标签大全CMS标签大全CMS标签大全CMS标签大全CMS标签大全CMS标签大全CMS标签大全
帝国CMS学生学习知识点总结作文试题练习题考试资讯网站源码 带手机版 帝国CMS《学习》模板,简洁大气访问快,带一个漂亮体验好的手机端,中小学生知识点总结、试题、练习题、考试资讯、作文大全,学习方法技巧等,百度...
APPCMS是一套专业的APP内容管理系统,APP应用部分需要结合数据中心使用。 APPCMS还提供了资讯、推荐位、专题、友链、正文内链等各种扩展模块,帮助站长更好的个性化自己的网站。 掌易科技以1:5-1:10的价格收购采用...