Nginx：session與nginx_upstream_jvm_route(轉(zhuǎn))

轉(zhuǎn)自http://hanqunfeng.iteye.com/blog/1920994

1）ip_hash（不推薦使用）

 nginx中的ip_hash技術(shù)能夠?qū)⒛硞€(gè)ip的請(qǐng)求定向到同一臺(tái)后端，這樣一來這個(gè)ip下的某個(gè)客戶端和某個(gè)后端就能建立起穩(wěn)固的session，ip_hash是在upstream配置中定義的： 

 

 不推薦使用的原因如下：

 

  1/ nginx不是最前端的服務(wù)器。

   ip_hash要求nginx一定是最前端的服務(wù)器，否則nginx得不到正確ip，就不能根據(jù)ip作hash。譬如使用的是squid為最前端，那么nginx取ip時(shí)只能得到squid的服務(wù)器ip地址，用這個(gè)地址來作分流是肯定錯(cuò)亂的。 

    2/ nginx的后端還有其它方式的負(fù)載均衡。

   假如nginx后端又有其它負(fù)載均衡，將請(qǐng)求又通過另外的方式分流了，那么某個(gè)客戶端的請(qǐng)求肯定不能定位到同一臺(tái)session應(yīng)用服務(wù)器上。

   3/ 多個(gè)外網(wǎng)出口。

    很多公司上網(wǎng)有多個(gè)出口，多個(gè)ip地址，用戶訪問互聯(lián)網(wǎng)時(shí)候自動(dòng)切換ip。而且這種情況不在少數(shù)。使用 ip_hash 的話對(duì)這種情況的用戶無效，無法將某個(gè)用戶綁定在固定的tomcat上 。

 

2)nginx_upstream_jvm_route(nginx擴(kuò)展，推薦使用)

nginx_upstream_jvm_route 是一個(gè)nginx的擴(kuò)展模塊，用來實(shí)現(xiàn)基于 Cookie 的 Session Sticky 的功能。

簡單來說，它是基于cookie中的JSESSIONID來決定將請(qǐng)求發(fā)送給后端的哪個(gè)server，nginx_upstream_jvm_route會(huì)在用戶第一次請(qǐng)求后端server時(shí)，將響應(yīng)的server標(biāo)識(shí)綁定到cookie中的JSESSIONID中，從而當(dāng)用戶發(fā)起下一次請(qǐng)求時(shí)，nginx會(huì)根據(jù)JSESSIONID來決定由哪個(gè)后端server來處理。

 

1/ nginx_upstream_jvm_route安裝

下載地址(svn)：http://nginx-upstream-jvm-route.googlecode.com/svn/trunk/

假設(shè)nginx_upstream_jvm_route下載后的路徑為/usr/local/nginx_upstream_jvm_route，

(1)進(jìn)入nginx源碼路徑

patch -p0 < /usr/local/nginx_upstream_jvm_route/jvm_route.patch

(2)./configure  --with-http_stub_status_module --with-http_ssl_module --prefix=/usr/local/nginx --with-pcre=/usr/local/pcre-8.33 --add-module=/usr/local/nginx_upstream_jvm_route

(3)make & make install

關(guān)于nginx的下載與安裝參考：http://hanqunfeng.iteye.com/blog/697696

 

2/ nginx配置

 3/ tomcat配置

修改192.168.33.10:8090tomcat的server.xml，

 同理，在192.168.33.11:8090server.xml中增加jvmRoute="tomcat02"。

4/ 測(cè)試

啟動(dòng)tomcat和nginx，訪問nginx代理，使用Google瀏覽器，F(xiàn)12，查看cookie中的JSESSIONID，

形如：ABCD123456OIUH897SDFSDF.tomcat01 ，刷新也不會(huì)變化

posted @ 2014-03-28 11:39 小秦 閱讀(533) | 評(píng)論 (0) | 編輯 收藏

nginx-sticky-module-1.1安裝不上

今天在安裝的時(shí)候出現(xiàn)這樣的錯(cuò)誤。

src/http/modules -I src/mail \

-o objs/addon/nginx-sticky-module-1.1/ngx_http_sticky_misc.o \ ../nginx-sticky-module-1.1/ngx_http_sticky_misc.c

In file included from ../nginx-sticky-module-1.1/ngx_http_sticky_misc.c:11:0: src/core/ngx_sha1.h:19:17: fatal error: sha.h: No such file or directory compilation terminated. make1?: [objs/addon/nginx-sticky-module-1.1/ngx_http_sticky_misc.o] Error 1 make1?: Leaving directory `/etc/nginx/nginx-1.4.1' make: build? Error 2

我的命令是

posted @ 2014-03-28 10:32 小秦 閱讀(4339) | 評(píng)論 (1) | 編輯 收藏

Nginx啟動(dòng)出錯(cuò) error while loading shared libraries:

[root@localhost conf]# /usr/local/nginx/sbin/nginx
/usr/local/nginx/sbin/nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
從錯(cuò)誤看出是缺少lib文件導(dǎo)致
可以看出 libpcre.so.1 => not found 并沒有找到，進(jìn)入/lib目錄中手動(dòng)鏈接下

[root@localhost lib]# ln -s libpcre.so.0.0.1 libpcre.so.1

然后在啟動(dòng)nginx ok 了
[root@localhost lib]# /usr/local/nginx/sbin/nginx
[root@localhost lib]# ps -ef |grep nginx
root 9539 1 0 19:06 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
www 9540 9539 0 19:06 ? 00:00:00 nginx: worker process

posted @ 2014-03-28 08:57 小秦 閱讀(222) | 評(píng)論 (0) | 編輯 收藏

安裝pcre

安裝pcre

PCRE是perl所用到的正則表達(dá)式，目的是讓所裝的軟件支持正則表達(dá)式。默認(rèn)情況下，Nginx只處理靜態(tài)的網(wǎng)頁請(qǐng)求，也就是html.如果是來自動(dòng)態(tài)的網(wǎng)頁請(qǐng)求，比如*.php，那么Nginx就要根據(jù)正則表達(dá)式查詢路徑，然后把*.PHP交給PHP去處理

#rpm -qa | grep pcre              //查詢系統(tǒng)中有沒有安裝PCRE，一般裝系統(tǒng)是默認(rèn)裝有，所以我們要?jiǎng)h掉系統(tǒng)自帶的

#cp /lib/libpcre.so.0 /            //在刪除系統(tǒng)自帶的PCRE之前，要先備份一下libpcre.so.0這個(gè)文件，因?yàn)镽PM包的關(guān)聯(lián)性太強(qiáng)，在刪除后沒libpcre.so.0這個(gè)文件時(shí)我們裝PCRE是裝不上的

#rpm -e --nodeps pcre-6.6-1.1           //刪除系統(tǒng)自帶的PCRE

# tar zxvf pcre-8.00.tar.gz

#cd pcre-8.00

#cp /libpcre.so.0 /lib/              //把我們刪除系統(tǒng)自帶的PCRE之前備份的libpcre.so.0拷貝到/lib 目錄下

#./configure         //配置PCRE，因?yàn)镻CRE是一個(gè)庫，而不是像pache、php、postfix等這樣的程序，所以我們安裝時(shí)選擇默認(rèn)路徑即可，這樣會(huì)在后面安裝其它東西時(shí)避免一些不必要的麻煩，執(zhí)行完這部后會(huì)顯示出下圖，上面顯示了我們對(duì)PCRE的配置

#make && make install

posted @ 2014-03-27 16:31 小秦 閱讀(432) | 評(píng)論 (0) | 編輯 收藏

使用nginx sticky實(shí)現(xiàn)基于cookie的負(fù)載均衡(轉(zhuǎn))

     摘要: 轉(zhuǎn)自http://www.ttlsa.com/nginx/nginx-modules-nginx-sticky-module/在多臺(tái)后臺(tái)服務(wù)器的環(huán)境下，我們?yōu)榱舜_保一個(gè)客戶只和一臺(tái)服務(wù)器通信，我們勢(shì)必使用長連接。使用什么方式來實(shí)現(xiàn)這種連接呢，常見的有使用nginx自帶的ip_hash來做，我想這絕對(duì)不是一個(gè)好的辦法，如果前端是CDN，或者說一個(gè)局域網(wǎng)的客戶同時(shí)訪問服務(wù)器，導(dǎo)致出現(xiàn)服務(wù)器分配不均衡，...  閱讀全文

posted @ 2014-03-27 16:31 小秦 閱讀(281) | 評(píng)論 (0) | 編輯 收藏

CentOS 防火墻開啟80端口以及已經(jīng)開啟的端口查看方法（轉(zhuǎn)）

CentOS 防火墻開啟80端口

網(wǎng)上搜索了很多都沒解決問題，下面是正確方法：

#/sbin/iptables -I INPUT -p tcp --dport 80 -j ACCEPT

#/sbin/iptables -I INPUT -p tcp --dport 22 -j ACCEPT

然后保存：

#/etc/rc.d/init.d/iptables save

如果上面的步驟還沒好的話，可能是這個(gè)iptables文件使用的是包含調(diào)用。

一般的在/etc/sysconfig/iptables這個(gè)路徑上

打開這個(gè)文件修改手動(dòng)添加就行了。

注意需要重啟服務(wù)哦：執(zhí)行service iptabels save 與 service iptables restart

端口查看方法:

[root@vcentos ~]# /etc/init.d/iptables status

Table: filter

Chain INPUT (policy ACCEPT)

num target prot opt source destination

1 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:80

2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80

3 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)

num target prot opt source destination

1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

posted @ 2014-03-26 17:35 小秦 閱讀(227) | 評(píng)論 (0) | 編輯 收藏

LINUX/UBUNTU下如何設(shè)置固定IP地址 （轉(zhuǎn)）驗(yàn)證有效

auto eth0 
#iface eth0 inet dhcp -- 這個(gè)是自動(dòng)ip的設(shè)置 
iface eth0 inet static 
address  [ip地址] 
netmask  [子網(wǎng)掩碼] 
gateway  [網(wǎng)關(guān)]

運(yùn)行如下命令重啟網(wǎng)絡(luò)服務(wù)：

posted @ 2014-03-26 16:18 小秦 閱讀(257) | 評(píng)論 (0) | 編輯 收藏

通向架構(gòu)師的道路（第四天）之Tomcat性能調(diào)優(yōu)-讓小貓飛奔（轉(zhuǎn)）

一、總結(jié)前一天的學(xué)習(xí)

從“第三天”的性能測(cè)試一節(jié)中，我們得知了決定性能測(cè)試的幾個(gè)重要指標(biāo)，它們是：

ü   吞吐量

ü   Responsetime

ü   Cpuload

ü   MemoryUsage

我們也在第三天的學(xué)習(xí)中對(duì)Apache做過了一定的優(yōu)化，使其最優(yōu)化上述4大核心指標(biāo)的讀數(shù)，那么我們的Apache調(diào)優(yōu)了，我們的Tomcat也作些相應(yīng)的調(diào)整，當(dāng)完成今的課程后，到時(shí)你的“小貓”到時(shí)真的會(huì)“飛”起來的，所以請(qǐng)用心看完，這篇文章一方面用來向那位曾寫過“Tomcat如何承受1000個(gè)用戶”的作都的敬，一方面又是這篇原文的一個(gè)擴(kuò)展，因?yàn)樵诎言牡闹R(shí)用到相關(guān)的兩個(gè)大工程中去后解決了：

1)      承受更大并發(fā)用戶數(shù)

2)      取得了良好的性能與改善（系統(tǒng)平均性能提升達(dá)20倍，極端一個(gè)交易達(dá)80倍）。

另外值的一提的是，我們當(dāng)時(shí)工程里用的“小貓”是跑在32位機(jī)下的， 也就是我們的JVM最大受到2GB內(nèi)存的限制，都已經(jīng)跑成“飛”了。。。。。。如果在64位機(jī)下跑這頭“小貓”。。。。。。大家可想而知，會(huì)得到什么樣的效果呢？下面就請(qǐng)請(qǐng)?jiān)敿?xì)的設(shè)置吧！

 

二、一切基于JVM（內(nèi)存）的優(yōu)化

2.1 32位操作系統(tǒng)與64位操作系統(tǒng)中JVM的對(duì)比

我們一般的開發(fā)人員，基本用的是都是32位的Windows系統(tǒng)，這就導(dǎo)致了一個(gè)嚴(yán)重的問題即：32位windows系統(tǒng)對(duì)內(nèi)存限制，下面先來看一個(gè)比較的表格：

操作系統(tǒng)	操作系統(tǒng)位數(shù)	內(nèi)存限制	解決辦法
Winxp	32	4GB	超級(jí)兔子
Win7	32	4GB	可以通過設(shè)置/PAE
Win2003	32	可以突破4GB達(dá)16GB	必需要裝win2003 advanced server且要打上sp2補(bǔ)丁
Win7	64	無限制	機(jī)器能插多少內(nèi)存，系統(tǒng)內(nèi)存就能支持到多大
Win2003	64	無限制	機(jī)器能插多少內(nèi)存，系統(tǒng)內(nèi)存就能支持到多大
Linux	64	無限制	機(jī)器能插多少內(nèi)存，系統(tǒng)內(nèi)存就能支持到多大
Unix	64	無限制	機(jī)器能插多少內(nèi)存，系統(tǒng)內(nèi)存就能支持到多大

上述問題解決后，我們又碰到一個(gè)新的問題，32位系統(tǒng)下JVM對(duì)內(nèi)存的限制：不能突破2GB內(nèi)存，即使你在Win2003 Advanced Server下你的機(jī)器裝有8GB-16GB的內(nèi)存，而你的JAVA，只能用到2GB的內(nèi)存。

其實(shí)我一直很想推薦大家使用Linux或者是Mac操作系統(tǒng)的，而且要裝64位，因?yàn)楸鼐刮覀兪情_發(fā)用的不是打游戲用的，而Java源自Unix歸于Unix（Linux只是運(yùn)行在PC上的Unix而己）。

所以很多開發(fā)人員運(yùn)行在win32位系統(tǒng)上更有甚者在生產(chǎn)環(huán)境下都會(huì)布署win32位的系統(tǒng)，那么這時(shí)你的Tomcat要優(yōu)化，就要講究點(diǎn)技巧了。而在64位操作系統(tǒng)上無論是系統(tǒng)內(nèi)存還是JVM都沒有受到2GB這樣的限制。

Tomcat的優(yōu)化分成兩塊：

ü   Tomcat啟動(dòng)命令行中的優(yōu)化參數(shù)即JVM優(yōu)化

ü   Tomcat容器自身參數(shù)的優(yōu)化（這塊很像ApacheHttp Server）

這一節(jié)先要講的是Tomcat啟動(dòng)命令行中的優(yōu)化參數(shù)。

Tomcat首先跑在JVM之上的，因?yàn)樗膯?dòng)其實(shí)也只是一個(gè)java命令行，首先我們需要對(duì)這個(gè)JAVA的啟動(dòng)命令行進(jìn)行調(diào)優(yōu)。

需要注意的是：

這邊討論的JVM優(yōu)化是基于Oracle Sun的jdk1.6版有以上，其它JDK或者低版本JDK不適用。

2.2 Tomcat啟動(dòng)行參數(shù)的優(yōu)化

Tomcat 的啟動(dòng)參數(shù)位于tomcat的安裝目錄\bin目錄下，如果你是Linux操作系統(tǒng)就是catalina.sh文件，如果你是Windows操作系統(tǒng)那么你需要改動(dòng)的就是catalina.bat文件。打開該文件，一般該文件頭部是一堆的由##包裹著的注釋文字，找到注釋文字的最后一段如：

# $Id: catalina.sh 522797 2007-03-27 07:10:29Z fhanik $ # -----------------------------------------------------------------------------   # OS specific support.  $var _must_ be set to either true or false.

敲入一個(gè)回車，加入如下的參數(shù)

Linux系統(tǒng)中tomcat的啟動(dòng)參數(shù)

export JAVA_OPTS="-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m  -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true "

Windows系統(tǒng)中tomcat的啟動(dòng)參數(shù)

set JAVA_OPTS=-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m  -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true

上面參數(shù)好多啊，可能有人寫到現(xiàn)在都沒見一個(gè)tomcat的啟動(dòng)命令里加了這么多參數(shù)，當(dāng)然，這些參數(shù)只是我機(jī)器上的，不一定適合你，尤其是參數(shù)后的value（值）是需要根據(jù)你自己的實(shí)際情況來設(shè)置的。

參數(shù)解釋：

ü   -server

我不管你什么理由，只要你的tomcat是運(yùn)行在生產(chǎn)環(huán)境中的，這個(gè)參數(shù)必須給我加上

因?yàn)閠omcat默認(rèn)是以一種叫java –client的模式來運(yùn)行的，server即意味著你的tomcat是以真實(shí)的production的模式在運(yùn)行的，這也就意味著你的tomcat以server模式運(yùn)行時(shí)將擁有：更大、更高的并發(fā)處理能力，更快更強(qiáng)捷的JVM垃圾回收機(jī)制，可以獲得更多的負(fù)載與吞吐量。。。更。。。還有更。。。

Y給我記住啊，要不然這個(gè)-server都不加，那是要打屁股了。

ü   -Xms–Xmx

即JVM內(nèi)存設(shè)置了，把Xms與Xmx兩個(gè)值設(shè)成一樣是最優(yōu)的做法，有人說Xms為最小值，Xmx為最大值不是挺好的，這樣設(shè)置還比較人性化，科學(xué)化。人性？科學(xué)？你個(gè)頭啊。

大家想一下這樣的場(chǎng)景：

一個(gè)系統(tǒng)隨著并發(fā)數(shù)越來越高，它的內(nèi)存使用情況逐步上升，上升到最高點(diǎn)不能上升了，開始回落，你們不要認(rèn)為這個(gè)回落就是好事情，由其是大起大落，在內(nèi)存回落時(shí)它付出的代價(jià)是CPU高速開始運(yùn)轉(zhuǎn)進(jìn)行垃圾回收，此時(shí)嚴(yán)重的甚至?xí)斐赡愕南到y(tǒng)出現(xiàn)“卡殼”就是你在好好的操作，突然網(wǎng)頁像死在那邊一樣幾秒甚至十幾秒時(shí)間，因?yàn)镴VM正在進(jìn)行垃圾回收。

因此一開始我們就把這兩個(gè)設(shè)成一樣，使得Tomcat在啟動(dòng)時(shí)就為最大化參數(shù)充分利用系統(tǒng)的效率，這個(gè)道理和jdbcconnection pool里的minpool size與maxpool size的需要設(shè)成一個(gè)數(shù)量是一樣的原理。

如何知道我的JVM能夠使用最大值啊？拍腦袋？不行！

在設(shè)這個(gè)最大內(nèi)存即Xmx值時(shí)請(qǐng)先打開一個(gè)命令行，鍵入如下的命令：

看，能夠正常顯示JDK的版本信息，說明，這個(gè)值你能夠用。不是說32位系統(tǒng)下最高能夠使用2GB內(nèi)存嗎？即：2048m，我們不防來試試

可以嗎？不可以！不要說2048m呢，我們小一點(diǎn)，試試1700m如何

嘿嘿，連1700m都不可以，更不要說2048m了呢，2048m只是一個(gè)理論數(shù)值，這樣說吧我這邊有幾臺(tái)機(jī)器，有的機(jī)器-Xmx1800都沒問題，有的機(jī)器最高只能到-Xmx1500m。

因此在設(shè)這個(gè)-Xms與-Xmx值時(shí)一定一定記得先這樣測(cè)試一下，要不然直接加在tomcat啟動(dòng)命令行中你的tomcat就再也起不來了，要飛是飛不了，直接成了一只瘟貓了。

ü   –Xmn

設(shè)置年輕代大小為512m。整個(gè)堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，所以增大年輕代后，將會(huì)減小年老代大小。此值對(duì)系統(tǒng)性能影響較大，Sun官方推薦配置為整個(gè)堆的3/8。

ü   -Xss

是指設(shè)定每個(gè)線程的堆棧大小。這個(gè)就要依據(jù)你的程序，看一個(gè)線程 大約需要占用多少內(nèi)存，可能會(huì)有多少線程同時(shí)運(yùn)行等。一般不易設(shè)置超過1M，要不然容易出現(xiàn)out ofmemory。

ü   -XX:+AggressiveOpts

作用如其名（aggressive），啟用這個(gè)參數(shù)，則每當(dāng)JDK版本升級(jí)時(shí)，你的JVM都會(huì)使用最新加入的優(yōu)化技術(shù)（如果有的話）

ü   -XX:+UseBiasedLocking

啟用一個(gè)優(yōu)化了的線程鎖，我們知道在我們的appserver，每個(gè)http請(qǐng)求就是一個(gè)線程，有的請(qǐng)求短有的請(qǐng)求長，就會(huì)有請(qǐng)求排隊(duì)的現(xiàn)象，甚至還會(huì)出現(xiàn)線程阻塞，這個(gè)優(yōu)化了的線程鎖使得你的appserver內(nèi)對(duì)線程處理自動(dòng)進(jìn)行最優(yōu)調(diào)配。

ü   -XX:PermSize=128M-XX:MaxPermSize=256M

JVM使用-XX:PermSize設(shè)置非堆內(nèi)存初始值，默認(rèn)是物理內(nèi)存的1/64；

在數(shù)據(jù)量的很大的文件導(dǎo)出時(shí)，一定要把這兩個(gè)值設(shè)置上，否則會(huì)出現(xiàn)內(nèi)存溢出的錯(cuò)誤。

由XX:MaxPermSize設(shè)置最大非堆內(nèi)存的大小，默認(rèn)是物理內(nèi)存的1/4。

那么，如果是物理內(nèi)存4GB，那么64分之一就是64MB，這就是PermSize默認(rèn)值，也就是永生代內(nèi)存初始大小；

四分之一是1024MB，這就是MaxPermSize默認(rèn)大小。

ü   -XX:+DisableExplicitGC

在程序代碼中不允許有顯示的調(diào)用”System.gc()”。看到過有兩個(gè)極品工程中每次在DAO操作結(jié)束時(shí)手動(dòng)調(diào)用System.gc()一下，覺得這樣做好像能夠解決它們的out ofmemory問題一樣，付出的代價(jià)就是系統(tǒng)響應(yīng)時(shí)間嚴(yán)重降低，就和我在關(guān)于Xms,Xmx里的解釋的原理一樣，這樣去調(diào)用GC導(dǎo)致系統(tǒng)的JVM大起大落，性能不到什么地方去喲！

ü   -XX:+UseParNewGC

對(duì)年輕代采用多線程并行回收，這樣收得快。

ü   -XX:+UseConcMarkSweepGC

即CMS gc，這一特性只有jdk1.5即后續(xù)版本才具有的功能，它使用的是gc估算觸發(fā)和heap占用觸發(fā)。

我們知道頻頻繁的GC會(huì)造面JVM的大起大落從而影響到系統(tǒng)的效率，因此使用了CMS GC后可以在GC次數(shù)增多的情況下，每次GC的響應(yīng)時(shí)間卻很短，比如說使用了CMS GC后經(jīng)過jprofiler的觀察，GC被觸發(fā)次數(shù)非常多，而每次GC耗時(shí)僅為幾毫秒。

ü   -XX:MaxTenuringThreshold

設(shè)置垃圾最大年齡。如果設(shè)置為0的話，則年輕代對(duì)象不經(jīng)過Survivor區(qū)，直接進(jìn)入年老代。對(duì)于年老代比較多的應(yīng)用，可以提高效率。如果將此值設(shè)置為一個(gè)較大值，則年輕代對(duì)象會(huì)在Survivor區(qū)進(jìn)行多次復(fù)制，這樣可以增加對(duì)象再年輕代的存活時(shí)間，增加在年輕代即被回收的概率。

這個(gè)值的設(shè)置是根據(jù)本地的jprofiler監(jiān)控后得到的一個(gè)理想的值，不能一概而論原搬照抄。

ü   -XX:+CMSParallelRemarkEnabled

在使用UseParNewGC 的情況下, 盡量減少 mark 的時(shí)間

ü   -XX:+UseCMSCompactAtFullCollection

在使用concurrent gc 的情況下, 防止 memoryfragmention, 對(duì)live object 進(jìn)行整理, 使 memory 碎片減少。

ü   -XX:LargePageSizeInBytes

指定 Java heap的分頁頁面大小

ü   -XX:+UseFastAccessorMethods

get,set 方法轉(zhuǎn)成本地代碼

ü   -XX:+UseCMSInitiatingOccupancyOnly

指示只有在 oldgeneration 在使用了初始化的比例后concurrent collector 啟動(dòng)收集

ü   -XX:CMSInitiatingOccupancyFraction=70

CMSInitiatingOccupancyFraction，這個(gè)參數(shù)設(shè)置有很大技巧，基本上滿足(Xmx-Xmn)*(100- CMSInitiatingOccupancyFraction)/100>=Xmn就不會(huì)出現(xiàn)promotion failed。在我的應(yīng)用中Xmx是6000，Xmn是512，那么Xmx-Xmn是5488兆，也就是年老代有5488 兆，CMSInitiatingOccupancyFraction=90說明年老代到90%滿的時(shí)候開始執(zhí)行對(duì)年老代的并發(fā)垃圾回收（CMS），這時(shí)還 剩10%的空間是5488*10%=548兆，所以即使Xmn（也就是年輕代共512兆）里所有對(duì)象都搬到年老代里，548兆的空間也足夠了，所以只要滿 足上面的公式，就不會(huì)出現(xiàn)垃圾回收時(shí)的promotion failed；

因此這個(gè)參數(shù)的設(shè)置必須與Xmn關(guān)聯(lián)在一起。

ü   -Djava.awt.headless=true

這個(gè)參數(shù)一般我們都是放在最后使用的，這全參數(shù)的作用是這樣的，有時(shí)我們會(huì)在我們的J2EE工程中使用一些圖表工具如：jfreechart，用于在web網(wǎng)頁輸出GIF/JPG等流，在winodws環(huán)境下，一般我們的app server在輸出圖形時(shí)不會(huì)碰到什么問題，但是在linux/unix環(huán)境下經(jīng)常會(huì)碰到一個(gè)exception導(dǎo)致你在winodws開發(fā)環(huán)境下圖片顯示的好好可是在linux/unix下卻顯示不出來，因此加上這個(gè)參數(shù)以免避這樣的情況出現(xiàn)。

上述這樣的配置，基本上可以達(dá)到：

ü   系統(tǒng)響應(yīng)時(shí)間增快

ü   JVM回收速度增快同時(shí)又不影響系統(tǒng)的響應(yīng)率

ü   JVM內(nèi)存最大化利用

ü   線程阻塞情況最小化

2.3 Tomcat容器內(nèi)的優(yōu)化

前面我們對(duì)Tomcat啟動(dòng)時(shí)的命令進(jìn)行了優(yōu)化，增加了系統(tǒng)的JVM可使用數(shù)、垃圾回收效率與線程阻塞情況、增加了系統(tǒng)響應(yīng)效率等還有一個(gè)很重要的指標(biāo)，我們沒有去做優(yōu)化，就是吞吐量。

還記得我們?cè)诘谌斓膶W(xué)習(xí)中說的，這個(gè)系統(tǒng)本身可以處理1000，你沒有優(yōu)化和配置導(dǎo)致它默認(rèn)只能處理25。因此下面我們來看Tomcat容器內(nèi)的優(yōu)化。

打開tomcat安裝目錄\conf\server.xml文件，定位到這一行：

<Connector port="8080" protocol="HTTP/1.1"

這一行就是我們的tomcat容器性能參數(shù)設(shè)置的地方，它一般都會(huì)有一個(gè)默認(rèn)值，這些默認(rèn)值是遠(yuǎn)遠(yuǎn)不夠我們的使用的，我們來看經(jīng)過更改后的這一段的配置：

<Connector port="8080" protocol="HTTP/1.1"           URIEncoding="UTF-8"  minSpareThreads="25" maxSpareThreads="75"           enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"           acceptCount="300"  maxThreads="300" maxProcessors="1000" minProcessors="5"           useURIValidationHack="false"                                                compression="on" compressionMinSize="2048"                                                compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"                redirectPort="8443" />

好大一陀唉。。。。。。

沒關(guān)系，一個(gè)個(gè)來解釋

ü   URIEncoding=”UTF-8”

使得tomcat可以解析含有中文名的文件的url，真方便，不像apache里還有搞個(gè)mod_encoding，還要手工編譯

ü   maxSpareThreads

maxSpareThreads 的意思就是如果空閑狀態(tài)的線程數(shù)多于設(shè)置的數(shù)目，則將這些線程中止，減少這個(gè)池中的線程總數(shù)。

ü   minSpareThreads

最小備用線程數(shù)，tomcat啟動(dòng)時(shí)的初始化的線程數(shù)。

ü   enableLookups

這個(gè)功效和Apache中的HostnameLookups一樣，設(shè)為關(guān)閉。

ü   connectionTimeout

connectionTimeout為網(wǎng)絡(luò)連接超時(shí)時(shí)間毫秒數(shù)。

ü   maxThreads

maxThreads Tomcat使用線程來處理接收的每個(gè)請(qǐng)求。這個(gè)值表示Tomcat可創(chuàng)建的最大的線程數(shù)，即最大并發(fā)數(shù)。

ü   acceptCount

acceptCount是當(dāng)線程數(shù)達(dá)到maxThreads后，后續(xù)請(qǐng)求會(huì)被放入一個(gè)等待隊(duì)列，這個(gè)acceptCount是這個(gè)隊(duì)列的大小，如果這個(gè)隊(duì)列也滿了，就直接refuse connection

ü   maxProcessors與minProcessors

在 Java中線程是程序運(yùn)行時(shí)的路徑，是在一個(gè)程序中與其它控制線程無關(guān)的、能夠獨(dú)立運(yùn)行的代碼段。它們共享相同的地址空間。多線程幫助程序員寫出CPU最 大利用率的高效程序，使空閑時(shí)間保持最低，從而接受更多的請(qǐng)求。

通常Windows是1000個(gè)左右，Linux是2000個(gè)左右。

ü   useURIValidationHack

我們來看一下tomcat中的一段源碼：

security         if (connector.getUseURIValidationHack()) {             String uri = validate(request.getRequestURI());             if (uri == null) {                 res.setStatus(400);                 res.setMessage("Invalid URI");                 throw new IOException("Invalid URI");             } else {                 req.requestURI().setString(uri);                 // Redoing the URI decoding                 req.decodedURI().duplicate(req.requestURI());                 req.getURLDecoder().convert(req.decodedURI(), true);             }         }

可以看到如果把useURIValidationHack設(shè)成"false"，可以減少它對(duì)一些url的不必要的檢查從而減省開銷。

ü   enableLookups="false"

為了消除DNS查詢對(duì)性能的影響我們可以關(guān)閉DNS查詢，方式是修改server.xml文件中的enableLookups參數(shù)值。

ü   disableUploadTimeout

類似于Apache中的keeyalive一樣

ü   給Tomcat配置gzip壓縮(HTTP壓縮)功能

compression="on" compressionMinSize="2048"              compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

HTTP 壓縮可以大大提高瀏覽網(wǎng)站的速度，它的原理是，在客戶端請(qǐng)求網(wǎng)頁后，從服務(wù)器端將網(wǎng)頁文件壓縮，再下載到客戶端，由客戶端的瀏覽器負(fù)責(zé)解壓縮并瀏覽。相對(duì)于普通的瀏覽過程HTML,CSS,Javascript , Text ，它可以節(jié)省40%左右的流量。更為重要的是，它可以對(duì)動(dòng)態(tài)生成的，包括CGI、PHP , JSP , ASP , Servlet,SHTML等輸出的網(wǎng)頁也能進(jìn)行壓縮，壓縮效率驚人。

1)compression="on" 打開壓縮功能

2)compressionMinSize="2048" 啟用壓縮的輸出內(nèi)容大小，這里面默認(rèn)為2KB

3)noCompressionUserAgents="gozilla, traviata" 對(duì)于以下的瀏覽器，不啟用壓縮

4)compressableMimeType="text/html,text/xml"　壓縮類型

最后不要忘了把8443端口的地方也加上同樣的配置，因?yàn)槿绻覀冏遠(yuǎn)ttps協(xié)議的話，我們將會(huì)用到8443端口這個(gè)段的配置，對(duì)吧？

<!--enable tomcat ssl-->     <Connector port="8443" protocol="HTTP/1.1"                URIEncoding="UTF-8"  minSpareThreads="25" maxSpareThreads="75"           enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"           acceptCount="300"  maxThreads="300" maxProcessors="1000" minProcessors="5"           useURIValidationHack="false"                     compression="on" compressionMinSize="2048"                     compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"                 SSLEnabled="true"            scheme="https" secure="true"            clientAuth="false" sslProtocol="TLS"            keystoreFile="d:/tomcat2/conf/shnlap93.jks" keystorePass="aaaaaa"       />

好了，所有的Tomcat優(yōu)化的地方都加上了。結(jié)合第三天中的Apache的性能優(yōu)化，我們這個(gè)架構(gòu)可以“飛奔”起來了，當(dāng)然這邊把有提及任何關(guān)于數(shù)據(jù)庫優(yōu)化的步驟，但僅憑這兩步，我們的系統(tǒng)已經(jīng)有了很大的提升。

舉個(gè)真實(shí)的例子：上一個(gè)項(xiàng)目，經(jīng)過4輪performance testing，第一輪進(jìn)行了問題的定位，第二輪就是進(jìn)行了apache+tomcat/weblogic的優(yōu)化，第三輪是做集群優(yōu)化，第四輪是sql與codes的優(yōu)化。

在到達(dá)第二輪時(shí)，我們的性能已經(jīng)提升了多少倍呢？我們來看一個(gè)loaderrunner的截圖吧：

左邊第一列是第一輪沒有經(jīng)過任何調(diào)優(yōu)的壓力測(cè)試報(bào)告。

右邊這一列是經(jīng)過了apache優(yōu)化，tomcat優(yōu)化后得到的壓力測(cè)試報(bào)告。

大家看看，這就提高了多少倍？這還只是在沒有改動(dòng)代碼的情況下得到的改善，現(xiàn)在明白了好好的調(diào)優(yōu)一

個(gè)apache和tomcat其實(shí)是多么的重要了？如果加上后面的代碼、SQL的調(diào)優(yōu)、數(shù)據(jù)庫的調(diào)優(yōu)。。。。。。所以我在上一個(gè)工程中有單筆交易性能（無論是吞吐量、響應(yīng)時(shí)間）提高了80倍這樣的極端例子的存在。
轉(zhuǎn)自：http://blog.csdn.net/lifetragedy/article/details/7708724

posted @ 2014-02-17 14:47 小秦 閱讀(314) | 評(píng)論 (0) | 編輯 收藏

Linux系統(tǒng)下如何查看及修改文件讀寫權(quán)限(轉(zhuǎn))

查看文件權(quán)限的語句： 
　　在終端輸入: 
　　ls -l xxx.xxx （xxx.xxx是文件名） 
　　那么就會(huì)出現(xiàn)相類似的信息，主要都是這些： 
　　-rw-rw-r-- 
　　一共有10位數(shù) 
　　其中： 最前面那個(gè) - 代表的是類型 
　　中間那三個(gè) rw- 代表的是所有者（user） 
　　然后那三個(gè) rw- 代表的是組群（group） 
　　最后那三個(gè) r-- 代表的是其他人（other） 
　　然后我再解釋一下后面那9位數(shù)： 
　　r 表示文件可以被讀（read） 
　　w 表示文件可以被寫（write） 
　　x 表示文件可以被執(zhí)行（如果它是程序的話） 
　　- 表示相應(yīng)的權(quán)限還沒有被授予 
　　現(xiàn)在該說說修改文件權(quán)限了 
　　在終端輸入： 
　　chmod o+w xxx.xxx 
　　表示給其他人授予寫xxx.xxx這個(gè)文件的權(quán)限 
　　chmod go-rw xxx.xxx 
　　表示刪除xxx.xxx中組群和其他人的讀和寫的權(quán)限 
　　其中： 
　　u 代表所有者（user） 
　　g 代表所有者所在的組群（group） 
　　o 代表其他人，但不是u和g （other） 
　　a 代表全部的人，也就是包括u，g和o 
　　r 表示文件可以被讀（read） 
　　w 表示文件可以被寫（write） 
　　x 表示文件可以被執(zhí)行（如果它是程序的話） 
　　其中：rwx也可以用數(shù)字來代替 

　　r ------------4 

　　w -----------2 

　　x ------------1 

　　- ------------0 

　　行動(dòng)： 

　　+ 表示添加權(quán)限 

　　- 表示刪除權(quán)限 

　　= 表示使之成為唯一的權(quán)限 

　　當(dāng)大家都明白了上面的東西之后，那么我們常見的以下的一些權(quán)限就很容易都明白了： 

　　-rw------- (600) 只有所有者才有讀和寫的權(quán)限 

　　-rw-r--r-- (644) 只有所有者才有讀和寫的權(quán)限，組群和其他人只有讀的權(quán)限 

　　-rwx------ (700) 只有所有者才有讀，寫，執(zhí)行的權(quán)限 

　　-rwxr-xr-x (755) 只有所有者才有讀，寫，執(zhí)行的權(quán)限，組群和其他人只有讀和執(zhí)行的權(quán)限 

　　-rwx--x--x (711) 只有所有者才有讀，寫，執(zhí)行的權(quán)限，組群和其他人只有執(zhí)行的權(quán)限 

　　-rw-rw-rw- (666) 每個(gè)人都有讀寫的權(quán)限 

　　-rwxrwxrwx (777) 每個(gè)人都有讀寫和執(zhí)行的權(quán)限 

posted @ 2014-02-17 14:45 小秦 閱讀(488) | 評(píng)論 (0) | 編輯 收藏

linux下VIRT,RES,SHR的含義（轉(zhuǎn)）

如題的三個(gè)字段雖說在man top下面都有解釋，但感覺有些含糊，看后難以理解它們對(duì)進(jìn)程資源占用的具體情況是如何的。查閱資料后，歸納一下。

VIRT：

1、進(jìn)程“需要的”虛擬內(nèi)存大小，包括進(jìn)程使用的庫、代碼、數(shù)據(jù)等

2、假如進(jìn)程申請(qǐng)100m的內(nèi)存，但實(shí)際只使用了10m，那么它會(huì)增長100m，而不是實(shí)際的使用量

RES：

1、進(jìn)程當(dāng)前使用的內(nèi)存大小，但不包括swap out

2、包含其他進(jìn)程的共享

3、如果申請(qǐng)100m的內(nèi)存，實(shí)際使用10m，它只增長10m，與VIRT相反

4、關(guān)于庫占用內(nèi)存的情況，它只統(tǒng)計(jì)加載的庫文件所占內(nèi)存大小

SHR：

1、除了自身進(jìn)程的共享內(nèi)存，也包括其他進(jìn)程的共享內(nèi)存

2、雖然進(jìn)程只使用了幾個(gè)共享庫的函數(shù)，但它包含了整個(gè)共享庫的大小

3、計(jì)算某個(gè)進(jìn)程所占的物理內(nèi)存大小公式：RES – SHR

4、swap out后，它將會(huì)降下來

posted @ 2014-02-17 14:45 小秦 閱讀(1409) | 評(píng)論 (0) | 編輯 收藏