发表于: 2019-12-08 15:10:05

1 1179


今天做了什么

给当前的WEB程序分别设置1G内存,512兆内存,32兆内存,测试最小启动的大小。

tomcat

修改bin目录下catalina.sh文件
在cygwin=false之上
添加修改

例如:

JAVA_OPTS="-Xms1024m -Xmx4096m -Xss1024K -XX:PermSize=512m -XX:MaxPermSize=2048m"
  • 参数详解:

  • -server: 一定要作为第一个参数,在多个CPU时性能佳 
  • -Xms:java Heap初始大小。 默认是物理内存的1/64。
  • -Xmx:java heap最大值。建议均设为物理内存的一半。不可超过物理内存。 
  • -XX:PermSize:设定内存的永久保存区初始大小,缺省值为64M。
  • -XX:MaxPermSize:设定内存的永久保存区最大 大小,缺省值为64M。
  • -XX:SurvivorRatio=2  :生还者池的大小,默认是2,如果垃圾回收变成了瓶颈,您可以尝试定制生成池设置
  • -XX:NewSize: 新生成的池的初始大小。 缺省值为2M。
  • -XX:MaxNewSize: 新生成的池的最大大小。缺省值为32M。

修改为32m时出现

搜索后发现




设置32m后再次启动发现访问不了,因为:

我的服务器是2g内存,所以tomcat启动不了


Kill命令和停止脚本的区别                      

执行kill命令,系统会发送一个SIGTERM信号给对应的程序。当程序接收到该signal信号后,将会发生以下事情:

程序立刻停止

当程序释放相应资源后再停止

程序可能仍然继续运行

大部分程序接收到SIGTERM信号后,会先释放自己的资源,然后再停止。但是也有程序可能接收信号后,做一些其他的事情(如果程序正在等待IO,可能就不会立马做出响应,我在使用wkhtmltopdf转pdf的项目中遇到这现象),也就是说,SIGTERM多半是会被阻塞的。

然而kill -9命令,系统给对应程序发送的信号是SIGKILL,即exit。exit信号不会被系统阻塞,所以kill -9能顺利杀掉进程


个人感觉:(不一定正确)执行停止脚本时会对当前工作和资源做一个保存,不会丢失信息,

kill相当于强制终止,可能会丢失当前工作(的相关信息),还有可能造成资源问题(连接丢失,资源泄露等等)

kill还可以杀死僵尸进程

编写部署脚本,部署到服务器的开发环境

编写shell脚本


部署脚本deploy.sh


#:/bin/sh
#自动部署脚本

#tomcat路径
tomcatBinPath=/tool/tomcat-8/bin

#war包和脚本目录
homepath=/tool/sh

echo '#####开始自动化部署#####'

#检查war包是否存在
cd $homepath
if [ $(find ./ -maxdepth 1 -name "*.war"|wc -l) -ne 1 ]; then
    echo '请保证文件夹homepath=/tool/sh中有且只有一个war包!'
    exit 1
fi


#进入tomcat目录
cd $tomcatBinPath
if [ $? -ne 0 ];then
    echo '请检查tomcat的bin路径是否正确!'
    exit 1
fi
echo "进入tomcat的bin目录:$tomcatBinPath"


pid=$(ps -fu `whoami`|grep "$tomcatBinPath"|grep -v grep|awk '{print $2}')
if [ -z "$pid" ];then
    echo "相关tomcat进程已关闭:$pid"
else
    ./shutdown.sh    #停止tomcat服务
    sleep 8
    kill -9 $pid
    echo '成功关闭tomcat服务!'
fi


#清空oldWarPackage目录
cd $homepath
if [ $? -ne 0 ];then
    echo '请检查homepath路径是否正确或者是否有权限进入!'
    exit 1
fi

if [ -d $homepath/oldWarPackage ];then
    echo "oldWarPackage文件夹存在!"
    rm -rf $homepath/oldWarPackage/*
else
    echo "oldWarPackage文件夹不存在!"
    mkdir $homepath/oldWarPackage
fi


cd $tomcatBinPath/../webapps/
if [ $? -ne 0 ];then
    echo '请检查webapps路径是否正确!'
    exit 1
fi
echo "进入webapps目录:$(pwd)"

cp *.war $homepath/oldWarPackage/
if [ $? -ne 0 ];then
    echo '请检查webapps下是否有war包或者oldWarPackage目录是否存在!'
    exit 1
fi

rm -rf *
cp $homepath/*.war ./

chown root:root *.war
chmod 755 *.war

cd $tomcatBinPath
./startup.sh

echo '--------部署结束--------'


回滚脚本 rollback.sh

#!/bin/bash
#回滚脚本

#war包和脚本目录
homepath=/tool/sh

cd $homepath/oldWarPackage
if [ $(find ./ -maxdepth 1 -name "*.war"|wc -l) -ne 1 ]; then
    echo '请保证文件夹/tool/sh中有且只有一个war包!'
    exit 1
fi

echo '------回滚开始------'
cd ../
rm -rf ./*.war
cp ./oldWarPackage/*.war ./
./deploy.sh
echo '------回滚结束------'


#    如果在Linux下使用vim命令编写脚本,需添加相关执行权限才能被执行(文件名变成绿色)。
#   如果在windows下编写的sh脚本,传到Linux上,需要增加相关执行权限,且需要格式转化
#   使用如下命令进行转换:
#  chmod 755 deploy.sh    //设置执行权限
#  dos2unix deploy.sh    //格式转化
#  busybox dos2unix deploy.sh    //如果提示dos2unix命令找不到,使用这条

执行--报错

解决方法:  https://blog.csdn.net/li_1303999/article/details/93159197

执行成功





对比JSON Tag-lib和直接用Spring 返回JSON对象

使用@ResponseBody和@RequestMapping(value = "/list", method = RequestMethod.GET)

指定restful路径(url)和方法(post、get、put、delete)


使用JSON Tag-lib比较麻烦,需要些jsp文件和使用JSON Tag-lib标签,使用spring直接返回比较方便,使用@Resposebody直接可以返回json数据


对比@RequestParam @RequestBody

https://blog.csdn.net/xuanwugang/article/details/79661672

HTTP请求构成:


①是请求方法,GET和POST是最常见的HTTP方法,除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。不过,当前的大多数浏览器只支持GET和POST,Spring 3.0提供了一个HiddenHttpMethodFilter,允许你通过“_method”的表单参数指定这些特殊的HTTP方法(实际上还是通过POST提交表单)。服务端配置了HiddenHttpMethodFilter后,Spring会根据_method参数指定的值模拟出相应的HTTP方法,这样,就可以使用这些HTTP方法对处理方法进行映射了。

②为请求对应的URL地址,它和报文头的Host属性组成完整的请求URL,③是协议名称及版本号。

④是HTTP的报文头,报文头包含若干个属性,格式为“属性名:属性值”,服务端据此获取客户端的信息。

 报文头包含若干个属性,格式为“属性名:属性值”,服务端据此获取客户端的信息
Accept:text/plain  response接受类型
Cache-Control: no-cache  
Accept-Charset:utf-8
Authorization:
Content-Type:  request体类型
host: 域名
refer: 转发

⑤是报文体,它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串,它承载多个请求参数的数据。不但报文体可以传递请求参数,请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。


@RequestParam
用来处理请求头Content-Type: 为 application/x-www-form-urlencoded编码的内容。(Http协议中,如果不指定Content-Type,则默认传递的参数就是application/x-www-form-urlencoded类型),get 方式中queryString的值,和post方式中 body data的值都会被Servlet接受到并转化到Request.getParameter()参数集中,所以@RequestParam可以获取的到。

RequestParam可以接受简单类型的属性,也可以接受对象类型。
实质是将Request.getParameter() 中的Key-Value参数Map利用Spring的转化机制ConversionService配置,转化成参数接收对象或字段。

 @RequestBody
用来处理请求头Content-Type: 为 application/json编码的内容,明确的告诉服务器发送的内容是json。因为需要读取body中内容,所以只能接受post请求。

遇到的问题

服务器tomcat启动慢、解决办法

在Tomcat的bin目录下找到catalina.sh,然后打开它,在以下位置添加一行代码:

-Djava.security.egd=file:/dev/urandom


Tomcat 7和Tomcat 8在启动的时候会调用org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom来产生一串安全随机数
在Linux(CentOS)环境下,随机数可以从两个特殊的文件中产生,一个是/dev/urandom,另外一个是/dev/random
它们产生随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特,然后将这些比特作为字节流返回。熵池就是当前系统的环境噪音,熵指的是一个系统的混乱程度,系统噪音可以通过很多参数来评估,如内存的使用,文件的使用量,不同类型的进程数量等等
/dev/random在不能产生新的随机数时会阻塞程序,直到根据熵池产生新的随机字节之后才返回;而/dev/urandom不会(ublock),当然,产生的随机数效果也不太好
所以我们强制Tomcat使用/dev/urandom而不是/dev/random来产生随机数,速度就会大幅提升


明天要做什么

完成参数检验和国际化

对demo进行改造,改为restful接口,将代码通过git部署到服务器并用Postman测试

学习nginx,学会使用反向代

如果还有时间进行任务二深度思考和任务总结,准备结束任务二



返回列表 返回列表
评论

    分享到