The NoteBook of EricKong

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  611 Posts :: 1 Stories :: 190 Comments :: 0 Trackbacks

#

SSL v2的设计顺应经典的公钥基础设施PKI(public key infrastructure)设计,后者认为一个服务器只提供一个服务从而也就只使用一个证书。这意味着服务器可以在TLS启动的早期阶段发送或提交证书,因为它知道它在为哪个域服务。HTTP服务器开启虚拟主机支持后,每个服务器通过相同的地址可以为很多域提供服务。服务器检查每一个请求来决定它在为哪个域服务。这个信息通常从HTTP请求头获得。不幸的是,当设置了TLS加密,服务器在读取HTTP请求里面的域名之前已经向客户端提交了证书,也就是已经为默认域提供了服务。因此,这种为虚拟主机提供安全的简单途径经常导致使用了错误的数字证书,从而导致浏览器对用户发出警告。
以上描述摘自OpenWares。详细了解请到:服务器名字指示SNI(Server Name Indication)
即访问www.buyberry.net会读取到beta.buyberry.net的证书,这样浏览器会报证书错误。
因此需要Server Name Indication (RFC 4366)这个扩展协议来修正。标准apache是支持Name Based SSL VHosts With SNI 。前提需要 OpenSSL 0.9.8f 之后才能支持。但是IHS并不支持这个扩展协议。
只能使用基于端口或者基于IP的虚拟主机来workaround
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443
Listen 444
NameVirtualHost www.buyberry.net:443
ServerName www.buyberry.net
SSLCipherSpec 34
SSLCipherSpec 35
SSLCipherSpec 3A
SSLCipherSpec 33
SSLCipherSpec 36
SSLCipherSpec 39
SSLCipherSpec 32
SSLCipherSpec 31
SSLCipherSpec 30
DocumentRoot “/ihs/htdocs”
SSLEnable
SSLClientAuth none
Keyfile “/ihs/sslkey20121227/key.kdb”
ErrorLog logs/ssl1_error_log
CustomLog logs/ssl1_access_log common env=!image
#########################################
NameVirtualHost beta.buyberry.net:444
ServerName beta.buyberry.net
SSLCipherSpec 34
SSLCipherSpec 35
SSLCipherSpec 3A
SSLCipherSpec 33
SSLCipherSpec 36
SSLCipherSpec 39
SSLCipherSpec 32
SSLCipherSpec 31
SSLCipherSpec 30
DocumentRoot “/ihs/htdocs”
SSLEnable
SSLClientAuth none
Keyfile “/ihs/2012key/2012key.kdb”
ErrorLog logs/ssl2_error_log
CustomLog logs/ssl2_access_log common env=!image
posted @ 2014-05-13 12:47 Eric_jiang 阅读(770) | 评论 (0)编辑 收藏

首先想到的就是dos输出是用系统的默认编码(gbk)的,我文件可是使用UTF-8编写的,肯定会出乱码楼。当时的想法就是在批处理文件中手动设置临时编码来进行输出,可是对这块不了解,百度吧,关键字:dos中设置编码,结果还真的有人遇到了这样的问题,不过是在做PHP项目中出现的,但是我也一样可以借用,呵呵。原来系统会有很多的字体代码的,在执行批处理前设置一下就OK了,命令如下:
chcp 65001 问题就解决了,65001是UTF-8的代码页,其他如下:
 
MS-DOS为以下国家和语言提供字符集:代码页描述
936 简体中文(默认)
950 繁体中文   
65001 UTF-8
1258 越南语
1257 波罗的语
1256 阿拉伯语
1255 希伯来语
1254 土耳其语
1253 希腊语
1252 拉丁 1 字符 (ANSI)
1251 西里尔语
1250 中欧语言
949 朝鲜语
932 日语
874 泰国语
850 多语种 (MS-DOS Latin1)
437 MS-DOS 美国英语
 
以上就是本次编写批处理命令中遇到的比较特殊的问题,以此记录,以备后用。
 
注:编写的批处理命令我在顶端空出来一行,才能使 chcp 65001 生效,这应该是和UTF-8文件有无BOM编码格式有关,我选择的是UTF-8有BOM编码格式保存的文件。
posted @ 2014-04-29 13:30 Eric_jiang 阅读(969) | 评论 (0)编辑 收藏

Hugepages是从Linux kernal 2.6后被引入的,其目的是使用更大的memory page size以适应越来越大的系统内存,使得oracle SGA这种大内存结构能分配到一个大块(hugepagesize)连续的内存,提高效率.


在Linux下,默认的page size大小为4k。默认的hugepagesize=2M。

我们来看看两者之间有什么区别

1. Page Table大小(小page size 可以节省内存,但提高管理成本page table的规模很大)

Page Table是用来存放虚拟内存也和物理内存页对应关系的内存结构。因为page size较小,所以相应的改内存结构也会比较大。

而Hugepages的常见page size为2M,是4k size的500倍,所以可以大大减小page table的size。

我们来看两个例子:

这是一个没有配置Hugepage的系统,系统内存128G,pagetable大小大约为4G。

cat /proc/meminfo

MemTotal: 132086880 kB
PageTables: 4059612 kB

这是配置了Hugepage的系统,系统内存96G, PageTable大小仅为78M

MemTotal: 98999880 kB
PageTables: 79916 kB

2. 大大提高了CPU cache中存放的page table所覆盖的内存大小,从而提高了TLB命中率

进程的虚拟内存地址段先连接到page tables然后再连接到物理内存。所以在访问内存时需要先访问page tables得到虚拟内存和物理内存的映射关系,然后再访问物理内存。

CPU cache中有一部分TLB(Translation Lookaside Buffer)用来存放部分page table以提高这种装换的速度。因为page size变大了,所以同样大小的TLB,所覆盖的内存大小也变大了。提高了TBL命中率,也就是提高了地址转换的速度。

3. 使用Hugepages的内存页是不会被交换出去的,永远常驻在内存中,所以也减少了内存也替换的额外开销

下面再说说在数据库服务器上使用Hugepages要注意的几点

1. Hugepages是在分配后就会预留出来的,其大小一定要比服务器上所有实例的SGA总和要大,差一点都不行。

比如说Hugepages设置为90G,oracle SGA为91G,那么oracle在启动的时候就不会使用到这90G的Hugepages。这90G就浪费了。所以在设置Hugepages时要计算SGA的大小,后面会给出一个脚本来计算。

2. 其他进程无法使用Hugepages的内存,所以不要设置太大,稍稍比SGA大一点保证SGA可以使用到hugepages就好了。

3. PGA不会使用Hugepages的内存。所以11g的AMM (Automatic Memory Management,memory_target参数)是不被支持的。而ASMM(Automatic Shared Memory Management, SGA_target参数)是被支持的,这两个不要搞混淆了。

4. 在meminfo中和Hugepage相关的有四项(RHEL5)

HugePages_Total: 43000
HugePages_Free: 29493
HugePages_Rsvd: 23550
Hugepagesize: 2048 kB

HugePages_Total为所分配的页面数目,和Hugepagesize相乘后得到所分配的内存大小。43000*2/1024大约为84GB
HugePages_Free为从来没有被使用过的Hugepages数目。即使oracle sga已经分配了这部分内存,但是如果没有实际写入,那么看到的还是Free的。这是很容易误解的地方
HugePages_Rsvd为已经被分配预留但是还没有使用的page数目。在Oracle刚刚启动时,大部分内存应该都是Reserved并且Free的,随着oracle SGA的使用,Reserved和Free都会不断的降低

HugePages_Free – HugePages_Rsvd 这部分是没有被使用到的内存,如果没有其他的oracle instance,这部分内存也许永远都不会被使用到,也就是被浪费了。在该系统上有11.5GB的内存被浪费了。

Note: RHEL4上的meminfo有所区别,没有HugePages_Rsvd这一项,并且当oracle instance启动时,所分配的内存就从free list上被移除掉了。也就是启动后HugePages_Free就是没有被SGA用到被浪费的内存。

最后说说如何设置HugePages:

1. 首先计算SGA大小已决定你要使用多少HugePages内存页。

你可以手工计算,如果使用了ASMM可以用SGA_Target/Hugepagesize,否则可以将 db_cache_size,large_pool_size, shared_pool_size,jave_pool_size, streams_pool_size五个部分加起来除以Hugepagesize。

或者可以先将oracle instance都起起来,然后ipcs -m查看共享内存段大小来计算。oracle在401749.1中也提供了一个脚本来帮助计算,脚本如下:

#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
#
# This script is provided by Doc ID 401749.1 from My Oracle Support
# http://support.oracle.com

# Welcome text
echo "
This script is provided by Doc ID 401749.1 from My Oracle Support
(http://support.oracle.com) where it is intended to compute values for
the recommended HugePages/HugeTLB configuration for the current shared
memory segments. Before proceeding with the execution please make sure
that:
 * Oracle Database instance(s) are up and running
 * Oracle Database 11g Automatic Memory Management (AMM) is not setup
   (See Doc ID 749851.1)
 * The shared memory segments can be listed by command:
     # ipcs -m

Press Enter to proceed..."

read

# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`

# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk '{print $2}'`

# Initialize the counter
NUM_PG=0

# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk '{print $5}' | grep "[0-9][0-9]*"`
do
   MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
   if [ $MIN_PG -gt 0 ]; then
      NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
   fi
done

RES_BYTES=`echo "$NUM_PG * $HPG_SZ * 1024" | bc -q`

# An SGA less than 100MB does not make sense
# Bail out if that is the case
if [ $RES_BYTES -lt 100000000 ]; then
   echo "***********"
   echo "** ERROR **"
   echo "***********"
   echo "Sorry! There are not enough total of shared memory segments allocated for
HugePages configuration. HugePages can only be used for shared memory segments
that you can list by command:

   # ipcs -m

of a size that can match an Oracle Database SGA. Please make sure that:
 * Oracle Database instance is up and running
 * Oracle Database 11g Automatic Memory Management (AMM) is not configured"
   exit 1
fi

# Finish with results
case $KERN in
   '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
          echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
   '2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    *) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac

# End

2. 关闭所有oracle实例

3. 用root设定oracle memlock limit,设置一个较大的数值或者unlimited

在/etc/security/limits.conf最后添加
oracle hard memlock unlimited
oracle soft memlock unlimited

4. 分配hugepages内存

在/etc/sysctl.conf中添加

vm.nr_hugepages = 46000 (step1′s value)

执行sysctl -p使其生效。这时候内存就已经被分配了,可以查看meminfo

grep Huge /proc/meminfo

HugePages_Total为设定的值大小,HugePages_Free应该和HugePages_Total一样大,HugePages_Rsvd为0.

5. 启动Oracle instance

这时候再次查看meminfo

HugePages_Total为设定的值大小不变,HugePages_Free有所降低,HugePages_Rsvd为一个较大的数值(因为刚刚启动时,大部分SGA被分配但是没有被使用到)。

如果Hugepages没有被使用,可能一些memory page被分配为4k大小了,那么需要重启server来设置。

从我们的测试结果看,Hugepages可以提高OLTP系统10%的吞吐量,当然不同的数据库应用结果可能不同,但是总体来说这是一个nice to have的设置。

posted @ 2014-04-16 14:31 Eric_jiang 阅读(312) | 评论 (0)编辑 收藏

SoftReference、Weak Reference和PhantomRefrence分析和比较

  本文将谈一下对SoftReference(软引用)、WeakReference(弱引用)和PhantomRefrence(虚引用)的理解,这三个类是对heap中java对象的应用,通过这个三个类可以和gc做简单的交互。

  强引用:

  除了上面提到的三个引用之外,还有一个引用,也就是最长用到的那就是强引用。例如:

Object o=new Object();   
Object o1=o;  

  上面代码中第一句是在heap堆中创建新的Object对象通过o引用这个对象,第二句是通过o建立o1到new Object()这个heap堆中的对象的引用,这两个引用都是强引用.只要存在对heap中对象的引用,gc就不会收集该对象.如果通过如下代码:

o=null;   
o1=null;

  如果显式地设置o和o1为null,或超出范围,则gc认为该对象不存在引用,这时就可以收集它了。可以收集并不等于就一会被收集,什么时候收集这要取决于gc的算法,这要就带来很多不确定性。例如你就想指定一个对象,希望下次gc运行时把它收集了,那就没办法了,有了其他的三种引用就可以做到了。其他三种引用在不妨碍gc收集的情况下,可以做简单的交互。

  heap中对象有强可及对象、软可及对象、弱可及对象、虚可及对象和不可到达对象。应用的强弱顺序是强、软、弱、和虚。对于对象是属于哪种可及的对象,由他的最强的引用决定。如下:

String abc=new String("abc");  //1   
SoftReference<String> abcSoftRef=new SoftReference<String>(abc);  //2   
WeakReference<String> abcWeakRef = new WeakReference<String>(abc); //3   
abc=null; //4   
abcSoftRef.clear();//5

  第一行在heap对中创建内容为“abc”的对象,并建立abc到该对象的强引用,该对象是强可及的。

  第二行和第三行分别建立对heap中对象的软引用和弱引用,此时heap中的对象仍是强可及的。

  第四行之后heap中对象不再是强可及的,变成软可及的。同样第五行执行之后变成弱可及的。

  SoftReference(软引用)

  软引用是主要用于内存敏感的高速缓存。在jvm报告内存不足之前会清除所有的软引用,这样以来gc就有可能收集软可及的对象,可能解决内存吃紧问题,避免内存溢出。什么时候会被收集取决于gc的算法和gc运行时可用内存的大小。当gc决定要收集软引用是执行以下过程,以上面的abcSoftRef为例:

  1、首先将abcSoftRef的referent设置为null,不再引用heap中的new String("abc")对象。

  2、将heap中的new String("abc")对象设置为可结束的(finalizable)。

  3、当heap中的new String("abc")对象的finalize()方法被运行而且该对象占用的内存被释放, abcSoftRef被添加到它的ReferenceQueue中。

  注:对ReferenceQueue软引用和弱引用可以有可无,但是虚引用必须有,参见:

Reference(T paramT, ReferenceQueue<? super T>paramReferenceQueue)  

  被 Soft Reference 指到的对象,即使没有任何 Direct Reference,也不会被清除。一直要到 JVM 内存不足且 没有 Direct Reference 时才会清除,SoftReference 是用来设计 object-cache 之用的。如此一来 SoftReference 不但可以把对象 cache 起来,也不会造成内存不足的错误 (OutOfMemoryError)。我觉得 Soft Reference 也适合拿来实作 pooling 的技巧。

     A obj = new A();
SoftRefenrence sr = new SoftReference(obj);

    //引用时
    if(sr!=null){
        obj = sr.get();
    }else{
        obj = new A();
        sr = new SoftReference(obj);
    }


 弱引用

  当gc碰到弱可及对象,并释放abcWeakRef的引用,收集该对象。但是gc可能需要对此运用才能找到该弱可及对象。通过如下代码可以了明了的看出它的作用:

String abc=new String("abc");    
WeakReference<String> abcWeakRef = new WeakReference<String>(abc);    
abc=null;    
System.out.println("before gc: "+abcWeakRef.get());    
System.gc();    
System.out.println("after gc: "+abcWeakRef.get());  

  运行结果:

  before gc: abc
  after gc: null

  gc收集弱可及对象的执行过程和软可及一样,只是gc不会根据内存情况来决定是不是收集该对象。

  如果你希望能随时取得某对象的信息,但又不想影响此对象的垃圾收集,那么你应该用 Weak Reference 来记住此对象,而不是用一般的 reference。

A obj = new A();

    WeakReference wr = new WeakReference(obj);

    obj = null;

    //等待一段时间,obj对象就会被垃圾回收
  ...

  if (wr.get()==null) { 
  System.out.println("obj 已经被清除了 "); 
  } else { 
  System.out.println("obj 尚未被清除,其信息是 "+obj.toString());
  }
  ...
}

  在此例中,透过 get() 可以取得此 Reference 的所指到的对象,如果返回值为 null 的话,代表此对象已经被清除。

  这类的技巧,在设计 Optimizer 或 Debugger 这类的程序时常会用到,因为这类程序需要取得某对象的信息,但是不可以 影响此对象的垃圾收集。

  PhantomRefrence(虚引用)

  虚顾名思义就是没有的意思,建立虚引用之后通过get方法返回结果始终为null,通过源代码你会发现,虚引用通向会把引用的对象写进referent,只是get方法返回结果为null。先看一下和gc交互的过程在说一下他的作用。

  1 不把referent设置为null,直接把heap中的new String("abc")对象设置为可结束的(finalizable).

  2 与软引用和弱引用不同,先把PhantomRefrence对象添加到它的ReferenceQueue中,然后在释放虚可及的对象。

  你会发现在收集heap中的new String("abc")对象之前,你就可以做一些其他的事情。通过以下代码可以了解他的作用。

import java.lang.ref.PhantomReference;    
import java.lang.ref.Reference;    
import java.lang.ref.ReferenceQueue;    
import java.lang.reflect.Field;    
   
public class Test {    
    public static boolean isRun = true;    
   
    public static void main(String[] args) throws Exception {    
        String abc = new String("abc");    
        System.out.println(abc.getClass() + "@" + abc.hashCode());    
        final ReferenceQueue referenceQueue = new ReferenceQueue<String>();    
        new Thread() {    
            public void run() {    
                while (isRun) {    
                    Object o = referenceQueue.poll();    
                    if (o != null) {    
                        try {    
                            Field rereferent = Reference.class   
                                    .getDeclaredField("referent");    
                            rereferent.setAccessible(true);    
                            Object result = rereferent.get(o);    
                            System.out.println("gc will collect:"   
                                    + result.getClass() + "@"   
                                    + result.hashCode());    
                        } catch (Exception e) {    
   
                            e.printStackTrace();    
                        }    
                    }    
                }    
            }    
        }.start();    
        PhantomReference<String> abcWeakRef = new PhantomReference<String>(abc,    
                referenceQueue);    
        abc = null;    
        Thread.currentThread().sleep(3000);    
        System.gc();    
        Thread.currentThread().sleep(3000);    
        isRun = false;    
    }    
   
}

  结果为:

  class java.lang.String@96354
  gc will collect:class java.lang.String@96354

posted @ 2014-03-21 17:01 Eric_jiang 阅读(214) | 评论 (0)编辑 收藏

Red5流媒体服务器简介

Red5是一个采用Java开发开源的Flash流媒体服务器。它支持:把音频(MP3)和视频(FLV)转换成播放流; 录制客户端播放流(只支持FLV);共享对象;现场直播流发布;远程调用。Red5使用RSTP作为流媒体传输协议,在其自带的一些示例中演示了在线录制,flash流媒体播放,在线聊天,视频会议等一些基本功能。

软件环境

既然是Java开发的,自然少不了要安装JDK,这里使用的是JDK6.x版本,Red5用的是0.9.1版本,Red5内嵌了Tomcat6.x服务器。为了测试和使用Red5,需要另外搭建开发环境,开发部署相应的服务端应用,开发IDE为Eclipse3.3.x + MyEclipse6.x(貌似版本有点低了,没办法,刚好电脑上安装程序,不想另外下载了,同时也够用了,哈哈),Web服务器为Tomcat6.x,最后客户端播放器使用Flowplayer3.2.x。以下是Red5和Flowplayer3.2.x下载地址。

Red5下载:http://www.red5.org/downloads/
CuSunPlayer流媒体播放器下载:http://www.CuPlayer.com/CuSunPlayer/

安装软件与环境配置

1.安装JDK。这里使用的是jdk-6u21-windows-i586.exe,双击按提示安装即可
 

完毕后设置环境变量JAVA_HOME,PATH和CLASSPATH,如何设置环境变量请谷歌或百度


2.安装Red5

因为是Windows环境,这里下载的是setup-Red5-0.9.1.exe。直接双击安装程序安装,安装过程中,需要填写服务器IP地址和端口,由于是本地测试,直接填写127.0.0.1,端口随意,不冲突即可,建议>1024,这里使用5050。安装完之后不要忘记设置RED5_HOME环境变量。

Red5安装程序会默认把Red5注册为系统服务自动启动,打开系统服务,查看是否服务是否已经存在:

我们看到服务已安装,但还没有启动,需要我们手动启动一下,选择Red5服务,鼠标右键,选择启动或者重新启动即可。系统界面操作,不赘述。如无意 外,应该可以正常启动。如果启动不了,请检查前面的环境变量设置是否设置完毕并且正确,最后检查Red5的启动日志文件,看看是否有相应的提示信息,日志 文件在Red5主目录下的log目录下,日志文件有多个,查看red5_service.log即可。启动后,打开浏览器,敲入安装Red5时的IP地址 和端口,正常情况下,看到如下信息,说明Red5已经正确安装了。

这个时候可以点击Install进入下载其官方提供的demo进行研究学习,安装后的demo文件在Red5根目录下的webapps下,如 D:\Red5\webapps。安装操作比较简单,这里不详细介绍,不过要这里要提醒一下,安装完的demo后,需要重新启动一下Red5服务器,重启 操作参考上面的介绍。

    3.安装配置开发环境

    主要安装配置Eclipse3.3.x + MyEclipse6.x +Tomcat6.x。

    Eclipse下载的是eclipse3.3.1.zip,直接解压到D:\Program Files目录下;Tomcat下载apache-tomcat-6.0.36-windows-x86.zip,直接解压到D:\ProgramFiles目录即可;然后安装MyEclipse6.x,这里用的是MyEclipse_6.0.1GA_E3.3.1_Installer.exe,双击按提示安装完毕即可。


    配置Tomcat服务器和默认字符集为UTF-8

    至此,软件的安装与环境配置完成,接下来就是开发和部署我们的流媒体服务器应用以及测试应用了。

posted @ 2014-03-18 15:44 Eric_jiang 阅读(1319) | 评论 (4)编辑 收藏

信息标注到google地图上(即在google本地商户中心登记您的公司信息和标注地理位置):
第一步:核实是否收录及正确性。
通过google地图(http://ditu.google.cn/)搜索您的公司,核实google地图是否已经收录你的公司信息。如果正确收录则无需再次添加。如果没有收录或者没有正确收录则需要添加或者修改不正确的信息。
第二步:录入公司信息及标注地理位置。
如果要修改已有信息,点击地图中公司信息下的“修改”进入本地商户中心;如果是新增加公司地图标注,则通过http://bendi.google.com/local/add进入。
录入基本信息(公司名称、地址、电话、网址等)、选择公司类别(最多5类)、可选择营业时间、可选择付款方式、可上传多个图片(最多10个)、可加载youtube视频(最多5个)等。如果地图自动标记的位置有误可手动调整。
google本地商户中心信息录入
第三步:验证
录入信息检查无误后进入到验证方式选择界面,验证所需的验证码(5位数字)可以选择电话获取(google自动语音系统拨打您的首选电话)或邮寄信函获取(google给您邮寄信函)。建议选择电话方式,可以在几秒中内获取验证码。(注意需要填写直拨号码而不是总机号码,并在google电话打过来时记录号验证码)。获取验证码后在商户列表页中填入验证码进行验证即可,成功验证后一个小时内您就可以看到贵公司在google地图中展示的效果了,赶快去试试吧。
验证方式选择界面
posted @ 2014-03-13 10:19 Eric_jiang 阅读(341) | 评论 (0)编辑 收藏

保存成日志文件形式的时候,大家经常会遇到一个问题:日志文件过大。上百兆的日志文件对 查阅日志信息来说也是一个问题。所以我希望能够每天或每个月产生一个日志文件,这样文件不至于过大。 或者根据日志文件大小来判断,超过规定大小,日志自动增加新文件。 
在log4j中这两种方式的实现都很简单,只要在配置文件中设置即可。 
一、按照一定时间产生日志文件,配置文件如下: 
# Set root logger level to ERROR and its only appender to A1. 
log4j.rootLogger=ERROR,R 
# R is set to be a DailyRollingFileAppender. 
log4j.appender.R=org.apache.log4j.DailyRollingFileAppender 
log4j.appender.R.File=backup.log 
log4j.appender.R.DatePattern = '.'yyyy-MM-dd 
log4j.appender.R.layout=org.apache.log4j.PatternLayout 
log4j.appender.R.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss} [%c]-[%p] %m%n 
以上配置是每天产生一个备份文件。其中备份文件的名字叫backup.log。 
具体的效果是这样:当天的日志信息记录在backup.log文件中,前一天的记录在名称为 backup.log.yyyy-mm-dd 的文件中。 
类似的,如果需要每月产生一个文件可以修改上面的配置: 
将 
log4j.appender.R.DatePattern = '.'yyyy-MM-dd 
改为 
log4j.appender.R.DatePattern = '.'yyyy-MM 
二、根据日志文件大小自动产生新日志文件 
配置文件内容如下: 
# Set root logger level to ERROR and its only appender to A1. 
log4j.rootLogger=ERROR,R 
# R is set to be a RollingFileAppender. 
log4j.appender.R=org.apache.log4j.RollingFileAppender 
log4j.appender.R.File=backup.log 
#log4j.appender.R.MaxFileSize=100KB 
# Keep one backup file 
log4j.appender.R.MaxBackupIndex=1 
log4j.appender.R.layout=org.apache.log4j.PatternLayout 
log4j.appender.R.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss} [%c]-[%p] %m%n 
其中: 
#日志文件的大小 
log4j.appender.R.MaxFileSize=100KB 
# 保存一个备份文件 
log4j.appender.R.MaxBackupIndex=1 
posted @ 2014-03-12 11:27 Eric_jiang 阅读(6709) | 评论 (2)编辑 收藏

SIP5.0以后服务的请求量爆发性增长,因此也暴露了原来没有暴露出来的问题。由于过去一般一个新版本发布周期在一个月左右,因此如果是小的内存泄露,在一个月之内重新发布以后也就看不出任何问题。 

因此这阵子除了优化Memcache客户端和SIP框架逻辑以外其他依赖部分以外,对于内存泄露的压力测试也开始实实在在的做起来。经过这次问题的定位和解决以后,大致觉得对于一个大用户量应用要放心的话,那么需要做这么几步。 

1.       在GC输出的环境下,大压力下做多天的测试。(可以在 JAVA_OPTS增加-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError) 

2.       检查GC输出日志来判断是否有内存泄露。(这部分后面有详细的实例说明) 

3.       如果出现内存泄露问题,则使用jprofiler等工具来排查内存泄露点(之所以不一开始使用,因为jprofiler等工具对于压力测试有影响,使得大压力无法上去,也使问题不那么容易暴露) 

4.       解决问题,并在重复2步骤。 

这里对SIP在jdk1.5和jdk1.6下做压力测试的GC 日志来做一个实际的分析对比,通过对比来大致描述一下如何根据输出情况能够了解应用是否存在内存泄露问题。(这里的内存泄露问题就是在以前blog写过的jdk的concurrent包内LinkedBlockingQueue的poll方法存在比较严重的内存泄露,调用频率越高,内存泄露的越厉害) 

两次压力测试都差不多都是两天,测试方案如下: 

开始50个并发,每个并发每次请求完毕后休息0.1秒,10分钟后增长50个并发,按此规律增长到500并发。 

旧版本SIP是在JDK1.5环境下完成的压力测试, 

新版本SIP的JDK版本是1.6, 

压力机和以前一样,是10.2.226.40,DELL1950,8CPU,8G内存。 

压力机模拟发出对一个需要签名的API不断的调用请求。 

看看两个Log的具体内容(内容很多截取部分做分析) 

先说一下日志输出的结构:(1.6和1.5略微有一些不同,只是1.6对于时间统计更加细致) 

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs] 

<collector>GC收集器的名称 

<starting occupancy1> 新生代在GC前占用的内存 

<ending occupancy1> 新生代在GC后占用的内存 

<pause time1> 新生代局部收集时jvm暂停处理的时间 

<starting occupancy3> JVM Heap 在GC前占用的内存 

<ending occupancy3> JVM Heap 在GC后占用的内存 

<pause time3> GC过程中jvm暂停处理的总时间 

Jdk1.5 log: 

启动时GC输出: 

[GC [DefNew: 209792K->4417K(235968K), 0.0201630 secs] 246722K->41347K(498112K), 0.0204050 secs] 

[GC [DefNew: 214209K->4381K(235968K), 0.0139200 secs] 251139K->41312K(498112K), 0.0141190 secs] 

一句输出: 

新生代回收前209792K,回收后4417K,回收数量205375K,Heap总量回收前246722K回收后41347K,回收总量205375K。这就表示100%的收回,没有任何新生代的对象被提升到中生代或者永久区(名字说的不一定准确,只是表达意思)。 

第二句输出: 

按照分析也就只是有1K内容被提升到中生代。 

运行一段时间后: 

[GC [DefNew: 210686K->979K(235968K), 0.0257140 secs] 278070K->68379K(498244K), 0.0261820 secs] 

[GC [DefNew: 210771K->1129K(235968K), 0.0275160 secs] 278171K->68544K(498244K), 0.0280050 secs] 

第一句输出: 

         新生代回收前210686K,回收后979K,回收数量209707K,Heap总量回收前278070K回收后68379K,回收总量209691K。这就表示有16k没有被回收。 

第二句输出: 

         新生代回收前210771K,回收后1129K,回收数量209642K,Heap总量回收前278171K回收后68544K,回收总量209627K。这就表示有15k没有被回收。 

比较一下启动时与现在的新生代占用内存情况和Heap使用情况发现Heap的使用增长很明显,新生代没有增长,而Heap使用总量增长了27M,这就表明可能存在内存泄露,虽然每一次泄露的字节数很少,但是频率很高,大部分泄露的对象都被升级到了中生代或者持久代。 

又一段时间后: 

[GC [DefNew: 211554K->1913K(235968K), 0.0461130 secs] 350102K->140481K(648160K), 0.0469790 secs] 

[GC [DefNew: 211707K->2327K(235968K), 0.0546170 secs] 350275K->140921K(648160K), 0.0555070 secs] 

第一句输出: 

         新生代回收前211554K,回收后1913K,回收数量209641K,Heap总量回收前350102K回收后140481K,回收总量209621K。这就表示有20k没有被回收。 



         分析到这里就可以看出每一次泄露的内存只有10几K,但是在大压力长时间的测试下,内存泄露还是很明显的,此时Heap已经增长到了140M,较启动时已经增长了100M。同时GC占用的时间越来越长。 

后续的现象: 

         后续观察日志会发现,Full GC的频率越来越高,收集所花费时间也是越来越长。(Full GC定期会执行,同时局部回收不能满足分配需求的情况下也会执行)。 



[Full GC [Tenured: 786431K->786431K(786432K), 3.4882390 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)], 3.4887920 secs] 

java.lang.OutOfMemoryError: Java heap space 

Dumping heap to java_pid7720.hprof ... 



         出现这个语句表示内存真的被消耗完了。 

Jdk1.6 log: 



启动时GC的输出: 

[GC [PSYoungGen: 221697K->31960K(229376K)] 225788K->36051K(491520K), 0.0521830 secs] [Times: user=0.26 sys=0.05, real=0.05 secs] 

[GC [PSYoungGen: 228568K->32752K(229376K)] 232659K->37036K(491520K), 0.0408620 secs] [Times: user=0.21 sys=0.02, real=0.04 secs] 



第一句输出: 

         新生代回收前221697K,回收后31960K,回收数量189737K,Heap总量回收前225788K回收后36051K,回收总量189737K。100%被回收。 



运行一段时间后输出: 

[GC [PSYoungGen: 258944K->2536K(259328K)] 853863K->598135K(997888K), 0.0471620 secs] [Times: user=0.15 sys=0.00, real=0.05 secs] 

[GC [PSYoungGen: 259048K->2624K(259328K)] 854647K->598907K(997888K), 0.0462980 secs] [Times: user=0.16 sys=0.02, real=0.04 secs] 



第一句输出: 

         新生代回收前258944K,回收后2536K,回收数量256408K,Heap总量回收前853863K回收后598135K,回收总量255728K。680K没有被回收,但这并不意味着就会产生内存泄露。同时可以看出GC回收时间并没有增加。 



在运行一段时间后输出: 

[GC [PSYoungGen: 258904K->2488K(259264K)] 969663K->713923K(1045696K), 0.0485140 secs] [Times: user=0.16 sys=0.01, real=0.04 secs] 

[GC [PSYoungGen: 258872K->2448K(259328K)] 970307K->714563K(1045760K), 0.0473770 secs] [Times: user=0.16 sys=0.01, real=0.05 secs] 



第一句输出: 

         新生代回收前258904K,回收后2488K,回收数量256416K,Heap总量回收前969663K回收后713923K,回收总量255740K。676K没有被回收,同时总的Heap也有所增加。 

         此时看起来好像和1.5的状况一样。但是查看了一下Full GC的执行还是400-500次GC执行一次,因此继续观察。 



运行一天多以后输出: 

[GC [PSYoungGen: 257016K->3304K(257984K)] 1019358K->766310K(1044416K), 0.0567120 secs] [Times: user=0.18 sys=0.01, real=0.06 secs] 

[GC [PSYoungGen: 257128K->2920K(258112K)] 1020134K->766622K(1044544K), 0.0549570 secs] [Times: user=0.19 sys=0.00, real=0.05 secs] 



可以发现Heap增长趋缓。 



运行两天以后输出: 

[GC [PSYoungGen: 256936K->3584K(257792K)] 859561K->606969K(1044224K), 0.0565910 secs] [Times: user=0.18 sys=0.01, real=0.06 secs] 

[GC [PSYoungGen: 256960K->3368K(257728K)] 860345K->607445K(1044160K), 0.0553780 secs] [Times: user=0.18 sys=0.01, real=0.06 secs] 



发现Heap反而减少了,此时可以对内存泄露问题作初步排除了。(其实在jdk1.6环境下用jprofiler来观察,对于concurrent那个内存泄露点的跟踪发现,内存的确还是会不断增长的,不过在一段时间后还是有回收,因此也就可以部分解释前面出现的情况) 



总结: 

         对于GC输出的观察需要分两个维度来看。一个是纵向比较,也就是一次回收对于内存变化的观察。一个是横向比较,对于长时间内存分配占用情况的比较,这部分比较需要较长时间的观察,不能仅仅凭短时间的几个抽样比较,因为对于抽样来说,Full GC前后的区别,运行时长的区别,资源瞬时占用的区别都会影响判断。同时要结合Full GC发生的时间周期,每一次GC收集所耗费的时间作为辅助判断标准。 

         顺便说一下,Heap的 YoungGen,OldGen,PermGen的设置也是需要注意的,并不是越大越好,越大执行收集的时间越久,但是可能执行Full GC的频率会比较低,因此需要权衡。这些仔细的去了解一下GC的基础设计思想会更有帮助,不过一般用默认的也不错。还有就是可以配置一些特殊的GC,并行,同步等等,充分利用多CPU的资源。 

         对于GC的优化可以通过现在很多图形工具来做,也可以类似于我这样采用最原始的分析方式,好处就是任何时间任何地点只要知道原理就可以分析无需借助外部工具。原始的总是最好的^_^。 
posted @ 2014-03-05 17:09 Eric_jiang 阅读(262) | 评论 (0)编辑 收藏

     摘要: 1、Java虚拟机运行时的数据区2、常用的内存区域调节参数-Xms:初始堆大小,默认为物理内存的1/64(<1GB);默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制-Xmx:最大堆大小,默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时,JVM会减少堆直到 -Xms的最小限制-Xmn:新生代的内存空间...  阅读全文
posted @ 2014-03-05 17:03 Eric_jiang 阅读(980) | 评论 (0)编辑 收藏

性能测试排查定位问题,分析调优过程中,会遇到要分析gc日志,人肉分析gc日志有时比较困难,相关图形化或命令行工具可以有效地帮助辅助分析。

Gc日志参数

通过在tomcat启动脚本中添加相关参数生成gc日志

-verbose.gc开关可显示GC的操作内容。打开它,可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。

打开-xx:+ printGCdetails开关,可以详细了解GC中的变化。

打开-XX: + PrintGCTimeStamps开关,可以了解这些垃圾收集发生的时间,自JVM启动以后以秒计量。

最后,通过-xx: + PrintHeapAtGC开关了解堆的更详细的信息。

为了了解新域的情况,可以通过-XX:=PrintTenuringDistribution开关了解获得使用期的对象权。

-Xloggc:$CATALINA_BASE/logs/gc.log gc日志产生的路径

XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间

-XX:+PrintGCDateStamps // GC发生的时间信息

 

Gc日志


日志中显示了gc发生的时间,young区回收情况,整体回收情况,fullGC情况,回收所消耗时间等

 

常用JVM参数

分析gc日志后,经常需要调整jvm内存相关参数,常用参数如下

-Xms初始堆大小,默认为物理内存的1/64(<1GB);默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制

-Xmx:最大堆大小,默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时,JVM会减少堆直到 -Xms的最小限制

-Xmn新生代的内存空间大小,注意:此处的大小是(eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小 + 老生代大小 + 永久代大小。 
在保证堆大小不变的情况下,增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio新生代中Eden区域与Survivor区域的容量比值,默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。一般小的应用, 如果栈不是很深, 应该是128k够用的,大的应用建议使用256k。这个选项对性能影响比较大,需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。

-XX:PermSize设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize设置持久代最大值。物理内存的1/4。

 

Gc日志分析工具

(1)GCHisto

http://java.net/projects/gchisto

 

直接点击gchisto.jar就可以运行,点add载入gc.log

统计了总共gc次数,youngGC次数,FullGC次数,次数的百分比,GC消耗的时间,百分比,平均消耗时间,消耗时间最小最大值等

 


统计的图形化表示

 

YoungGC,FullGC不同消耗时间上次数的分布图,勾选可以显示youngGC或fullGC单独的分布情况

 

整个时间过程详细的gc情况,可以对整个过程进行剖析

 

 

(2)GCLogViewer

 

http://code.google.com/p/gclogviewer/

 

点击run.bat运行

 

整个过程gc情况的趋势图,还显示了gc类型,吞吐量,平均gc频率,内存变化趋势等

Tools里还能比较不同gc日志


 


(3)HPjmeter

 

获取地址 http://www.hp.com/go/java
参考文档 http://www.javaperformancetuning.com/tools/hpjtune/index.shtml

 

工具很强大,但只能打开由以下参数生成的GC log, -verbose:gc -Xloggc:gc.log,添加其他参数生成的gc.log无法打开。

 

(4)GCViewer

http://www.tagtraum.com/gcviewer.html

这个工具用的挺多的,但只能在JDK1.5以下的版本中运行,1.6以后没有对应。

(5)garbagecat

http://code.google.com/a/eclipselabs.org/p/garbagecat/wiki/Documentation

 

 

其它监控方法

Jvisualvm动态分析jvm内存情况和gc情况,插件:visualGC

  

jvisualvm还可以heapdump出对应hprof文件(默认存放路径:监控的服务器 /tmp下),利用相关工具,比如HPjmeter可以对其进行分析

grep Full gc.log粗略观察FullGC发生频率

jstat –gcutil [pid] [intervel] [count]

jmap -histo pid可以观测对象的个数和占用空间
jmap -heap pid可以观测jvm配置参数,堆内存各区使用情况

jprofiler,jmap dump出来用MAT分析

 

如果要分析的dump文件很大的话,就需要很多内存,很容易crash。

所以在启动时,我们应该加上一些参数: Java –Xms512M –Xmx1024M –Xss8M 

posted @ 2014-03-05 16:58 Eric_jiang 阅读(5892) | 评论 (0)编辑 收藏

仅列出标题
共57页: First 上一页 9 10 11 12 13 14 15 16 17 下一页 Last