精华内容
下载资源
问答
  • 今天在部署一个开源项目的时候,Tomcat8启动异常,报错信息: Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: PermGen space 根据报错信息我们可以看出是堆内存不够。...

     今天在部署一个开源项目的时候,Tomcat8启动异常,报错信息:

    Exception in thread "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: PermGen space

    根据报错信息我们可以看出是堆内存不够。所以需要手动设置堆内存大小,即MaxPermSize的大小。

    在{$TOMCAT_HOME}/bin/catalina.sh中,找到“echo "Using CATALINA_BASE: $CATALINA_BASE"”,在上面加入以下行:

    JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m"

     当然具体堆内存大小设置,还是要根据机器内存大小。

     最后的修改后的内容是 

     

     

     

    展开全文
  • Linux Tomcat8启动很慢

    2017-09-30 17:09:53
     加入后再启动Tomcat,整个启动耗时下降到Server startup in 2912 ms。 2)在JVM环境中解决  打开$JAVA_PATH/jre/lib/security/java.security这个文件,找到下面的内容: securerandom.source=file:/dev/...
    Log4j:[2017-08-2715:47:11]  INFO ReadProperty:172 - Loading properties file from class path resource [resources/jdbc.properties]
    Log4j:[2017-08-27 15:47:11]  INFO ReadProperty:172 - Loading properties file from class path resource [resources/common.properties]
    27-Aug-2017 15:52:53.587 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [342,445] milliseconds.

    原因

    Tomcat 7/8都使用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom类产生安全随机类SecureRandom的实例作为会话ID,这里花去了342秒,也即接近6分钟。

    SHA1PRNG算法是基于SHA-1算法实现且保密性较强的伪随机数生成器。

    在SHA1PRNG中,有一个种子产生器,它根据配置执行各种操作。

    1)如果java.security.egd属性或securerandom.source属性指定的是”file:/dev/random”或”file:/dev/urandom”,那么JVM会使用本地种子产生器NativeSeedGenerator,它会调用super()方法,即调用SeedGenerator.URLSeedGenerator(/dev/random)方法进行初始化。

    2)如果java.security.egd属性或securerandom.source属性指定的是其它已存在的URL,那么会调用SeedGenerator.URLSeedGenerator(url)方法进行初始化。

    这就是为什么我们设置值为”file:///dev/urandom”或者值为”file:/./dev/random”都会起作用的原因。

    在这个实现中,产生器会评估熵池(entropy pool)中的噪声数量。随机数是从熵池中进行创建的。当读操作时,/dev/random设备会只返回熵池中噪声的随机字节。/dev/random非常适合那些需要非常高质量随机性的场景,比如一次性的支付或生成密钥的场景。

    当熵池为空时,来自/dev/random的读操作将被阻塞,直到熵池收集到足够的环境噪声数据。这么做的目的是成为一个密码安全的伪随机数发生器,熵池要有尽可能大的输出。对于生成高质量的加密密钥或者是需要长期保护的场景,一定要这么做。

    那么什么是环境噪声?

    随机数产生器会手机来自设备驱动器和其它源的环境噪声数据,并放入熵池中。产生器会评估熵池中的噪声数据的数量。当熵池为空时,这个噪声数据的收集是比较花时间的。这就意味着,Tomcat在生产环境中使用熵池时,会被阻塞较长的时间。

    解决

    有两种解决办法:

    1)在Tomcat环境中解决

     可以通过配置JRE使用非阻塞的Entropy Source。

     在catalina.sh中加入这么一行:-Djava.security.egd=file:/dev/./urandom 即可。

     加入后再启动Tomcat,整个启动耗时下降到Server startup in 2912 ms。

    2)在JVM环境中解决

     打开$JAVA_PATH/jre/lib/security/java.security这个文件,找到下面的内容:
    securerandom.source=file:/dev/urandom

    替换成
    securerandom.source=file:/dev/./urandom

    展开全文
  • LinuxTomcat 8启动很慢,且日志上无任何错误,在日志中查看到如下信息: Log4j:[2017-08-2715:47:11] INFO ReadProperty:172 - Loading properties file from class path resource [resources/jdbc.properties] ...

    问题

    Linux下Tomcat 8启动很慢,且日志上无任何错误,在日志中查看到如下信息:

    Log4j:[2017-08-2715:47:11]  INFO ReadProperty:172 - Loading properties file from class path resource [resources/jdbc.properties]
    Log4j:[2017-08-27 15:47:11]  INFO ReadProperty:172 - Loading properties file from class path resource [resources/common.properties]
    27-Aug-2017 15:52:53.587 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [342,445] milliseconds.

    原因

    Tomcat 7/8都使用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom类产生安全随机类SecureRandom的实例作为会话ID,这里花去了342秒,也即接近6分钟。

    SHA1PRNG算法是基于SHA-1算法实现且保密性较强的伪随机数生成器。

    在SHA1PRNG中,有一个种子产生器,它根据配置执行各种操作。

    1)如果java.security.egd属性或securerandom.source属性指定的是”file:/dev/random”或”file:/dev/urandom”,那么JVM会使用本地种子产生器NativeSeedGenerator,它会调用super()方法,即调用SeedGenerator.URLSeedGenerator(/dev/random)方法进行初始化。

    2)如果java.security.egd属性或securerandom.source属性指定的是其它已存在的URL,那么会调用SeedGenerator.URLSeedGenerator(url)方法进行初始化。

    这就是为什么我们设置值为”file:///dev/urandom”或者值为”file:/./dev/random”都会起作用的原因。

    在这个实现中,产生器会评估熵池(entropy pool)中的噪声数量。随机数是从熵池中进行创建的。当读操作时,/dev/random设备会只返回熵池中噪声的随机字节。/dev/random非常适合那些需要非常高质量随机性的场景,比如一次性的支付或生成密钥的场景。

    当熵池为空时,来自/dev/random的读操作将被阻塞,直到熵池收集到足够的环境噪声数据。这么做的目的是成为一个密码安全的伪随机数发生器,熵池要有尽可能大的输出。对于生成高质量的加密密钥或者是需要长期保护的场景,一定要这么做。

    那么什么是环境噪声?

    随机数产生器会手机来自设备驱动器和其它源的环境噪声数据,并放入熵池中。产生器会评估熵池中的噪声数据的数量。当熵池为空时,这个噪声数据的收集是比较花时间的。这就意味着,Tomcat在生产环境中使用熵池时,会被阻塞较长的时间。

    解决

    有两种解决办法:

    1)在Tomcat环境中解决

     可以通过配置JRE使用非阻塞的Entropy Source。

     在catalina.sh中加入这么一行:-Djava.security.egd=file:/dev/./urandom 即可。

     加入后再启动Tomcat,整个启动耗时下降到Server startup in 2912 ms。

    2)在JVM环境中解决

     打开$JAVA_PATH/jre/lib/security/java.security这个文件,找到下面的内容:
    securerandom.source=file:/dev/urandom

    替换成
    securerandom.source=file:/dev/./urandom

     

     

    展开全文
  • linux下面tomcat8启动慢的问题

    千次阅读 2017-05-31 14:20:13
    linux下面tomcat8启动慢的问题 今天在阿里云上使用tomcat8,结果启动了好半天才启动起来,重启主机等操作都不好使,仔细观察tomcat日志,发现有如下日志: 31-May-2017 13:50:32.127 INFO [main] org.apache....

    linux下面tomcat8启动慢的问题

    今天在阿里云上使用tomcat8,结果启动了好半天才启动起来,重启主机等操作都不好使,仔细观察tomcat日志,发现有如下日志:

    31-May-2017 13:50:32.127 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.5.14
    31-May-2017 13:52:32.356 INFO [localhost-startStop-1] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [119,978] milliseconds.
    

    就去百度和Google了

    原因

    Tomcat 7/8都使用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom类产生安全随机类SecureRandom的实例作为会话ID,这里花去了342秒,也即接近6分钟。

    SHA1PRNG算法是基于SHA-1算法实现且保密性较强的伪随机数生成器。

    在SHA1PRNG中,有一个种子产生器,它根据配置执行各种操作。

    1)如果Java.security.egd属性或securerandom.source属性指定的是”file:/dev/random”或”file:/dev/urandom”,那么JVM会使用本地种子产生器NativeSeedGenerator,它会调用super()方法,即调用SeedGenerator.URLSeedGenerator(/dev/random)方法进行初始化。

    2)如果java.security.egd属性或securerandom.source属性指定的是其它已存在的URL,那么会调用SeedGenerator.URLSeedGenerator(url)方法进行初始化。

    这就是为什么我们设置值为”file:///dev/urandom”或者值为”file:/./dev/random”都会起作用的原因。

    在这个实现中,产生器会评估熵池(entropy pool)中的噪声数量。随机数是从熵池中进行创建的。当读操作时,/dev/random设备会只返回熵池中噪声的随机字节。/dev/random非常适合那些需要非常高质量随机性的场景,比如一次性的支付或生成密钥的场景。

    当熵池为空时,来自/dev/random的读操作将被阻塞,直到熵池收集到足够的环境噪声数据。这么做的目的是成为一个密码安全的伪随机数发生器,熵池要有尽可能大的输出。对于生成高质量的加密密钥或者是需要长期保护的场景,一定要这么做。

    那么什么是环境噪声?

    随机数产生器会手机来自设备驱动器和其它源的环境噪声数据,并放入熵池中。产生器会评估熵池中的噪声数据的数量。当熵池为空时,这个噪声数据的收集是比较花时间的。这就意味着,Tomcat在生产环境中使用熵池时,会被阻塞较长的时间。

    解决

    有两种解决办法:

    1)在Tomcat环境中解决

    可以通过配置JRE使用非阻塞的Entropy Source。

    在catalina.sh中加入这么一行:-Djava.security.egd=file:/dev/./urandom 即可。

    加入后再启动Tomcat,整个启动耗时下降到Server startup in 2912 ms。

    2)在JVM环境中解决

    打开$JAVA_PATH/jre/lib/security/java.security这个文件,找到下面的内容:

    securerandom.source=file:/dev/urandom
    

    替换成

    securerandom.source=file:/dev/./urandom
    

    JVM上的随机数与熵池策略

    在apache-tomcat官方文档:如何让tomcat启动更快 里面提到了一些启动时的优化项,其中一项是关于随机数生成时,采用的“熵源”(entropy source)的策略。

    他提到tomcat7的session id的生成主要通过java.security.SecureRandom生成随机数来实现,随机数算法使用的是”SHA1PRNG”

    private String secureRandomAlgorithm = “SHA1PRNG”;
    在sun/oracle的jdk里,这个算法的提供者在底层依赖到操作系统提供的随机数据,在linux上,与之相关的是/dev/random和/dev/urandom,对于这两个设备块的描述以前也见过讨论随机数的文章,wiki中有比较详细的描述,摘抄过来,先看/dev/random :

    在读取时,/dev/random设备会返回小于熵池噪声总数的随机字节。/dev/random可生成高随机性的公钥或一次性密码本。若熵池空了,对/dev/random的读操作将会被阻塞,直到收集到了足够的环境噪声为止
    而 /dev/urandom 则是一个非阻塞的发生器:

    dev/random的一个副本是/dev/urandom (”unlocked”,非阻塞的随机数发生器),它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞,但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器,不建议用于生成高强度长期密码。
    另外wiki里也提到了为什么linux内核里的随机数生成器采用SHA1散列算法而非加密算法,是为了避开法律风险(密码出口限制)。

    回到tomcat文档里的建议,采用非阻塞的熵源(entropy source),通过java系统属性来设置:

    -Djava.security.egd=file:/dev/./urandom
    这个系统属性egd表示熵收集守护进程(entropy gathering daemon),但这里值为何要在dev和random之间加一个点呢?是因为一个jdk的bug,在这个bug的连接里有人反馈及时对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random,有人提供了变通的解决方法,其中一个变通的做法是对securerandom.source设置为 /dev/./urandom 才行。也有人评论说这个不是bug,是有意为之。

    我看了一下我当前所用的jdk7的java.security文件里,配置里仍使用的是/dev/urandom:

    #
    # Select the source of seed data for SecureRandom. By default an
    # attempt is made to use the entropy gathering device specified by
    # the securerandom.source property. If an exception occurs when
    # accessing the URL then the traditional system/thread activity
    # algorithm is used.
    #
    # On Solaris and Linux systems, if file:/dev/urandom is specified and it
    # exists, a special SecureRandom implementation is activated by default.
    # This "NativePRNG" reads random bytes directly from /dev/urandom.
    #
    # On Windows systems, the URLs file:/dev/random and file:/dev/urandom
    # enables use of the Microsoft CryptoAPI seed functionality.
    #
    securerandom.source=file:/dev/urandom
    

    我不确定jdk7里,这个 /dev/urandom 也同那个bug报告里所说的等同于 /dev/random;要使用非阻塞的熵池,这里还是要修改为/dev/./urandom 呢,还是jdk7已经修复了这个问题,就是同注释里的意思,只好验证一下。

    使用bug报告里给出的代码:

    import java.security.SecureRandom;
    class JRand {
    public static void main(String args[]) throws Exception {
        System.out.println("Ok: " +
            SecureRandom.getInstance("SHA1PRNG").nextLong());
    }
    

    }
    然后设置不同的系统属性来验证,先是在我的mac上:

    % time java -Djava.security.egd=file:/dev/urandom  JRand
    Ok: 8609191756834777000
    java -Djava.security.egd=file:/dev/urandom JRand  
    0.11s user 0.03s system 115% cpu 0.117 total
    
    % time java -Djava.security.egd=file:/dev/./urandom  JRand
    Ok: -3573266464480299009
    java -Djava.security.egd=file:/dev/./urandom JRand  
    0.11s user 0.03s system 116% cpu 0.116 total
    

    可以看到/dev/urandom和 /dev/./urandom 的执行时间差不多,有点纳闷,再仔细看一下wiki里说的:

    FreeBSD操作系统实现了256位的Yarrow算法变体,以提供伪随机数流。与Linux的/dev/random不同,FreeBSD的/dev/random不会产生阻塞,与Linux的/dev/urandom相似,提供了密码学安全的伪随机数发生器,而不是基于熵池。而FreeBSD的/dev/urandom则只是简单的链接到了/dev/random。
    尽管在我的mac上/dev/urandom并不是/dev/random的链接,但mac与bsd内核应该是相近的,/dev/random也是非阻塞的,/dev/urandom是用来兼容linux系统的,这两个随机数生成器的行为是一致的。参考这里。

    然后再到一台ubuntu系统上测试:

    % time java -Djava.security.egd=file:/dev/urandom  JRand
    Ok: 6677107889555365492
    java -Djava.security.egd=file:/dev/urandom JRand  
    0.14s user 0.02s system 9% cpu 1.661 total
    
    % time java -Djava.security.egd=file:/dev/./urandom  JRand
    Ok: 5008413661952823775
    java -Djava.security.egd=file:/dev/./urandom JRand  
    0.12s user 0.02s system 99% cpu 0.145 total
    

    这回差异就完全体现出来了,阻塞模式的熵池耗时用了1.6秒,而非阻塞模式则只用了0.14秒,差了一个数量级,当然代价是转换为对cpu的开销了。

    // 补充,连续在ubuntu上测试几次/dev/random方式之后,导致熵池被用空,被阻塞了60秒左右。应用服务器端要避免这种方式。
    后续继续研究补充吧。

    参考链接:http://blog.csdn.net/chszs/article/details/49494701
    http://hongjiang.info/jvm-random-and-entropy-source/

    展开全文
  • LinuxTomcat 8启动很慢,且日志上无任何错误,在日志中查看到如下信息: Log4j:[2017-08-2715:47:11] INFO ReadProperty:172 - Loading properties file from class path resource [resources/jdbc.properties] ...
  • 原生安装tomcat8之后,启动 ./startup.sh 报错 /usr/local/tomcat/tomcat8/logs/catalina.out: 没有那个文件或目录 检查发现没有配置日志输出文件路径: mkdir /usr/local/tomcat8/logs 正常启动:
  • linuxtomcat8启动很慢

    2017-09-07 15:12:31
    CentOS7下安装了tomcat8之后,直接启动,大概过了5min的样子才启动成功。 二、问题原因 查阅网上资料之后,主要原因是:启动tomcat时,需要生成随机数,这个过程很耗时间。 三、解决方案 (1)方案一 参照博客:...
  • 主要给大家介绍了关于在Linux系统下Tomcat8启动速度很慢的解决方法,需要的朋友可以参考下
  • 生成sessionID用掉8分钟 在/etc/profile里添加环境变量: export JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom
  • 今天分享下 —— Linux安装Tomcat8启动或停止tomcat服务的一些基本知识,欢迎关注! ????分享 前置条件 安装jdk,Linux安装JDK-配置环境(详细图解) 下载tomcat8 先从tomcat网站上下载最新的.gz安装包 ...
  • linux tomcat启动设置

    2013-11-11 13:48:00
    国内私募机构九鼎控股打造... esac exit $RETVAL 3、添加执行权限 sudo chmod +x /etc/init.d/tomcat 4、随系统启动 chkconfig --add tomcat 5、重启系统 转载于:https://www.cnblogs.com/AloneSword/p/3417812.html
  • 解压方式 下载tomcat.tat.gz文件,执行 tar -zxvf apache-tomcat-7.0.93.tar.gz 将压缩文件解压,进入tomcat下的bin...启动 命令行方式 root用户:apt-get install tomcat7 普通用户:sudo apt-get in...
  • 我正在使用Vagrant部署到Ubuntu Linux并尝试启动tomcat8服务.Tomcat 8由apt-get install tomcat8安装.使用服务tomcat8 start命令时,出现以下错误:Job for tomcat8.service Failed. See “systemctl status tomcat8....
  • tomcat8Linux下安装使用一段时间后启动非常慢,6分钟左右。 原因是一个随机数生成参数导致的。     处理如下:(以实验,有效) 修改catalina.sh .配置JRE使用非阻塞的Entropy Source if [ -z "$...
  • linux tomcat 开机自启动

    2020-06-10 16:30:04
    #!/bin/sh # chkconfig: 2345 10 90 # description: Start and Stop redis # Simple Redis init.d script conceived to work on Linux ...export CATALINA_HOME=/opt/tomcat8/ case "$1" in start) ${CATALINA_HO.
  • 今天在服务器上部署网站时 启动tomcat无错 tail -f catalina.out日志 和 catalina.sh run 方式启动时 卡在22-Jul-2016 23:00:53.921 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig....
  • 1. 在/etc/init.d 下新建一个文件 tomcat,并添加内容如下: #!/bin/sh # chkconfig: 345 99 10 # description: Auto-starts tomcat # /etc/init.d/tomcatd # Tomcat auto-start # Source function library. #. /...
  • linux启动tomcat8很慢

    2019-04-07 23:23:00
    今天将服务器tomcat7升级为tomcat8,但是在启动的时候非常慢,只跑了三个项目,启动耗时在3分钟左右。而在没升级tomcat之前,启动都在30秒内。 问题原因是tomcat在启动时会调用类的SecureRandom generateSeed()...
  • linuxtomcat 8的安装以及tomcat启动慢问题 https://www.cnblogs.com/ipyanthony/p/9366745.html
  • linux tomcat8 配置 jmx监控

    千次阅读 2016-04-17 10:36:17
    linux tomcat8 配置 jmx监控linux tomcat8 配置 jmx监控 编辑tomcatbincatalinash 编辑jmxremoteaccess和jmxremotepassword 重新启动 tomcat 用jvisualvm验证是否可用 mac terminal 直接输入jvisualvmjdk 默认自带的...
  • 进入tomcat的bin目录下面创建文文件setenv.sh #!/bin/sh export CATALINA_HOME=/home/ctl/soft/apache-tomcat-8.5.8/ echo $CATALINA_HOME/logs logback配置如下 <property name="LOG_HOME" value...
  • linux启动tomcat

    千次阅读 2018-10-09 22:44:33
    我的系统:deepin(linux) 15.7 64位 tomcat 8.0.53 不建议安装最新的tomcat,由于需要编程需要用...tomcat8的官网 下载之后,在终端解压 unzip 文件名.zip 进入tomcat的启动文件 cd 文件名/bin  更改文...
  • 服务器:Centos7 ,Tomcat8 ,JDK8 项目启动报错: OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000000077d800000, 362807296, 0) failed; error='Cannot allocate memory' (errno=12)   # ...
  • 今天在 linux 下安装了 tomcat,中间也是一路波折,最终安装好了。感觉应该有不少伙伴跟我一样都会踩到这些坑,打算记录下来。使用的是通用(ubantu,debian, centos 均可)的安装方式,安装也可以灵活一点。 下载 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 667
精华内容 266
关键字:

linuxtomcat8启动

linux 订阅