設(shè)置了 scanPeriod 之后，過了好長(zhǎng)時(shí)間，都不生效，后來 debug 代碼。發(fā)現(xiàn)了下面這段。

  private volatile long mask = 0xF;
@Override
public FilterReply decide(Marker marker, Logger logger, Level level,
String format, Object[] params, Throwable t) {
if (!isStarted()) {
return FilterReply.NEUTRAL;
}
// for performance reasons, skip change detection (MASK-1) times out of MASK.
// Only once every MASK calls is change detection code executed
// Note that MASK is a variable itself.
if (((invocationCounter++) & mask) != mask) {
return FilterReply.NEUTRAL;
}
long now = System.currentTimeMillis();
synchronized (configurationWatchList) {
updateMaskIfNecessary(now);
if (changeDetected(now)) {
// Even though reconfiguration involves resetting the loggerContext,
// which clears the list of turbo filters including this instance, it is
// still possible for this instance to be subsequently invoked by another
// thread if it was already executing when the context was reset.
disableSubsequentReconfiguration();
detachReconfigurationToNewThread();
}
}
return FilterReply.NEUTRAL;
}

這行 if (((invocationCounter++) & mask) != mask) { mask = 0xf，其實(shí)要每循環(huán) 0xf 次，也就是 15 次，才會(huì)去 check 一次是否要更新，也就是說，不管過了多久，如果沒到這 15 次，也不會(huì)去檢查是否更新配置。
也就是說，我多打幾次 log，配置文件就生效了。

spring security（下簡(jiǎn)寫為 ss）控制的安全主要有兩方面，Web 和 Method Call，這兩個(gè)方面的權(quán)限控制有比較多的相通的設(shè)計(jì)，也有一些特別的功能。比如 Method Call 可以做 After Invocation 控制，而 Web 可以做 Ip 地址控制。

這里面有兩個(gè)最基本的概念：authentication manager 和 access decision manager，前者控制認(rèn)證，后都控制鑒權(quán)。
1. 在 ss 的認(rèn)證系統(tǒng)中，默認(rèn)的實(shí)現(xiàn)幫助我們提供了三個(gè)概念，用戶（user），角色（authority，一般存 role）和組（group），三者的關(guān)系是，組、角色與用戶都是多對(duì)多關(guān)系，組和角色間沒關(guān)系，默認(rèn)是不啟用組的。后續(xù)，在 Acl 權(quán)限管理中，可以看到角色之間，是可以有包含（樹形？）關(guān)系的。
2. 在 ss 的鑒權(quán)系統(tǒng)中，明顯會(huì)比認(rèn)證復(fù)雜得多。有 AccessDecisionManager, AccessDecisionVoter（前置）, AfterInvocationProvider（后置）, RoleHierarchy, SidRetrievalStrategy, LookupStrategy, PermissionGrantingStrategy, SecurityExpressionHandler, AclService, MutableAclService, AclCache 概念過多了，要一個(gè)一個(gè)解釋
a) 中心是 AccessDecisionManager，主要負(fù)責(zé) AccessDecisionVoter 的管理，默認(rèn)提供了3種實(shí)現(xiàn)：1. AffirmativeBased 如果有任何一個(gè)投票器允許訪問,請(qǐng)求將被立刻允許,而不管之前可能有的拒絕決定。2. ConsensusBased 多數(shù)票(允許或拒絕)決定了結(jié)果，平局的投票 和空票(全是棄權(quán)的)的結(jié)果是可配置的。3. UnanimousBased 所有的投票器必須全是允許的,否則訪問將 被拒絕。
AccessDecisionManager 在用于 Web 和 Method Call 兩種情況下，可能是不一致的，因?yàn)楣δ芤膊灰恢隆?br /> b) Method Call 除了使用 AccessDecisionManager 進(jìn)行權(quán)限判斷外，還可以增加 AfterInvocationProvider 來進(jìn)行出口數(shù)據(jù)的判斷，默認(rèn)提供了 3 種。
1) PostInvocationAdviceProvider: 需要提供一個(gè) PostInvocationAuthorizationAdvice，默認(rèn)實(shí)現(xiàn)只有一個(gè)，就是 ExpressionBasedPostInvocationAdvice，可以通過 spel 來進(jìn)行權(quán)限判斷。注意 ExpressionBasedPostInvocationAdvice 中需要提供一個(gè) MethodSecurityExpressionHandler，能夠創(chuàng)建出一個(gè) MethodSecurityExpressionOperations，放到 spel context 中，供 spel function 調(diào)用，這樣的方式，在后續(xù)很常見。
2) AclEntryAfterInvocationProvider 和 AclEntryAfterInvocationCollectionFilteringProvider : 這兩種都差不多，主要依賴 AclService, ObjectIdentityRetrievalStrategy, SidRetrievalStrategy 來配合，檢查返回值的權(quán)限。Collection 版本的，可以把無(wú)權(quán)限的數(shù)據(jù)去掉，只留下有權(quán)限的數(shù)據(jù)。
c) RoleHierarchy 提供了角色之間的關(guān)系，提供了兩個(gè)實(shí)現(xiàn)，一個(gè)是沒關(guān)系的，直接把 user 的 role 返回，另外一個(gè)是有繼承關(guān)系的。繼承關(guān)系實(shí)現(xiàn)挺有意思的，能夠處理多級(jí)的 include 關(guān)系，比較好用。
RoleHierarchy 的使用比較復(fù)雜，會(huì)被 AccessDecisionVoter, SidRetrievalStrategy, SecurityExpressionHandler 用到，SecurityExpressionHandler 又會(huì)被 AccessDecisionVoter 用到，所以還是有點(diǎn)兒混亂。
具體的說 SecurityExpressionHandler 會(huì)用到 PermissionEvaluator 和 RoleHierarchy，PermissionEvaluator 的一個(gè)實(shí)現(xiàn) AclPermissionEvaluator 會(huì)用到 SidRetrievalStrategy。
d) SidRetrievalStrategy 和 RoleHierarchy 的功能比較接近，比 RoleHierarchy 高一個(gè)抽象層次，功能上也有所區(qū)別，是從一個(gè) authentication 拿到所有相關(guān)的 Sid（包括 Role（GrantedAuthoritySid） 和 User（PrincipalSid）），而 RoleHierarchy 只包括了 Role（GrantedAuthoritySid）的繼承關(guān)系。
e) LookupStrategy 通過 ObjectIdentity 和 Sid 把相關(guān)的 Acl 查詢出來。可以在 LookupStrategy 擴(kuò)展 Acl 和 Ace 的功能，比如在 Ace 上面加上時(shí)間的條件限制，就需要自己定義 LookupStrategy，把時(shí)間條件從數(shù)據(jù)庫(kù)查詢出來，并放到自定義的 Ace 當(dāng)中。
但這件事情非常麻煩，因?yàn)槟J(rèn)實(shí)現(xiàn)的 BasicLookupStrategy 是個(gè) Final 的類，所以只能自己直接實(shí)現(xiàn)接口，無(wú)法使用現(xiàn)有的功能。
LookupStrategy 會(huì)生成 Acl，而最終的權(quán)限驗(yàn)證是由 Acl 完成的，如果想驗(yàn)證帶時(shí)間條件的 Ace，需要給 Acl 設(shè)置自定義的帶有檢查時(shí)間功能的 PermissionGrantingStrategy，實(shí)際上，這個(gè) PermissionGrantingStrategy 會(huì)首先設(shè)置給 LookupStrategy，LookupStrategy 在創(chuàng)建 Acl 的時(shí)候，再放到 Acl 中去。
f) SecurityExpressionHandler 能夠執(zhí)行 spel，得到是否可以訪問的結(jié)果，它的子類都是繼承自 AbstractSecurityExpressionHandler 的，有一個(gè)非常重要的方法是 SecurityExpressionOperations createSecurityExpressionRoot(Authentication authentication, T invocation)，創(chuàng)建一個(gè) SecurityExpressionOperations 放到 EvaluationContext 中去，提供 spel 中執(zhí)行的方法實(shí)現(xiàn)。比如 SecurityExpressionOperations 的一個(gè)抽象實(shí)現(xiàn) SecurityExpressionRoot 中，就包含了大量的權(quán)限驗(yàn)證方法，如 hasRole, hasPermission 等常用的功能。
g) AclService, MutableAclService, AclCache 概念比較簡(jiǎn)單，AclService 是通過 LookupStrategy 查詢 Acl，自已可以查詢 ObjectIdentity 的父子關(guān)聯(lián)關(guān)系，MutableAclService 提供了修改的能力，AclCache 為 AclService 提供緩存，默認(rèn)的實(shí)現(xiàn)了一個(gè) EhCacheBasedAclCache。
3. ss 的鑒權(quán)模型 Sid, ObjectIdentity, Acl, Ace, Permission
a) Sid: 是中心，所有的授權(quán)會(huì)關(guān)聯(lián)在 Sid 上面，Sid 和之前的 Role Base Permission 會(huì)有些相同的地方，但也明顯不同，Sid 默認(rèn)實(shí)現(xiàn)情況下，分為 GrantedAuthoritySid 和 PrincipalSid，其實(shí)就是 Role 和 User，通過 SidRetrievalStrategy 拿到一個(gè) Authentication 的 Sid。
b) ObjectIdentity: 可以理解成 Resource，就是可訪問的目標(biāo)資源，有 id 和 type 兩個(gè)字段，默認(rèn)實(shí)現(xiàn)的 ObjectIdentityImpl 會(huì)直接調(diào)用目標(biāo) domainObject 的 getClass 和 getId 方法拿到兩個(gè)參數(shù)。在 PermissionEvaluator, AfterInvocationProvider 中，會(huì)用到 ObjectIdentityRetrievalStrategy 和 ObjectIdentityGenerator，ObjectIdentityRetrievalStrategy 會(huì)根據(jù) domainObject 拿到 ObjectIdentity，然后使用 Acl 進(jìn)行鑒權(quán)，ObjectIdentityGenerator 會(huì)在系統(tǒng)提供的不是 domainObject，而是 type, id 的時(shí)候，拿到 ObjectIdentity，然后進(jìn)行 Acl 鑒權(quán)，這兩個(gè)接口有一個(gè)共同的實(shí)現(xiàn) ObjectIdentityRetrievalStrategyImpl，如果需要在 ObjectIdentity 進(jìn)行新的抽象，需要用新的實(shí)現(xiàn)，到得不同的 ObjectIdentity，比如將業(yè)務(wù)對(duì)象分類鑒權(quán)這樣的需求。
c) Acl, 每個(gè) ObjectIdentity 最多對(duì)應(yīng)一條 Acl，Acl 中包含了很多，包括 parental，說明 Acl 是有繼承關(guān)系的？其實(shí)不是，呵呵，是 ObjectIdentity 有繼承關(guān)系而已。有一個(gè) ObjectIdentity，有很多 Sid，還有一個(gè)叫做 Owner 的 Sid，有從 LookupStrategy 傳過來的 PermissionGrantingStrategy，進(jìn)行實(shí)際的鑒權(quán)，還有 AclAuthorizationStrategy 檢查有沒有權(quán)限進(jìn)行 Acl security check。實(shí)現(xiàn)時(shí)間條件檢查，就擴(kuò)展 PermissionGrantingStrategy。
為什么沒有 RoleHierarchy 或是 SidRetrievalStrategy 存在呢？是因?yàn)檎{(diào)用 Acl 進(jìn)行權(quán)限檢查之前，已經(jīng)把相關(guān)的 Sid 得到了，再給 Acl 的。
d) Ace, Permission: Ace 存儲(chǔ) Sid, Permission，提供給 Acl 鑒權(quán)用。增加時(shí)間條件的話，最基本的，就是要在 Ace 中，增加時(shí)間條件字段。Permission 是用二進(jìn)制存儲(chǔ)的，但默認(rèn)實(shí)現(xiàn)的數(shù)據(jù)庫(kù)存儲(chǔ)并不是，是一個(gè)一條，存在數(shù)據(jù)庫(kù)里面的。

好吧，概念還是非常多的，不過鑒于權(quán)限控制本身就是個(gè)復(fù)雜的話題，ss 這些設(shè)計(jì)的我覺得已經(jīng)非常好，也基本夠用了。

主要完成了下面4個(gè)工作

1. 創(chuàng)建一個(gè)本地的目錄結(jié)構(gòu)，以存放 rpm 包
2. 啟動(dòng)一個(gè) apache，使這些文件能夠遠(yuǎn)程訪問
3. 寫一個(gè) spec，并且用 rpmbuild 做成一個(gè)安裝包，用來在機(jī)器上安裝新的 repository 位置
4. 使用 yum downloadonly plugin 將需要的 rpm 包放到本地目錄下，然后使用 createrepo 命令創(chuàng)建 metadata

本來是希望能有一個(gè)類似于 nexus 這樣的 proxy host server 將遠(yuǎn)程的 package cache 下來，找來找去，也找到了一個(gè) nexus yum plugin，但這個(gè) plugin 只支持手工的 deploy rpm package 到 nexus 上面，不能做 proxy 方式的。

寫寫步驟和遇到的問題吧。

準(zhǔn)備工作

• 安裝 createrepo, yum install createrepo
• 安裝 yum download only plugin, yum -y install yum-downloadonly
• 安裝 rpmbuild, yum -y install rpm-build
• 確認(rèn)已經(jīng)安裝了 apache nginx 之類的 http server

服務(wù)器步驟

• 首先是創(chuàng)建目錄結(jié)構(gòu)，比如 mkdir -p /data/yum/centos/6/x86_64
• 先增加 chef 的源，rpm -Uvh http://rbel.frameos.org/rbel6
• 然后是通過 yum -y install rubygem-chef-server –downloadonly –downloaddir=/data/yum/centos/6/x86_64
• 這時(shí)，已經(jīng)可以去掉 chef 的公共源了，rpm -e rbel6-release
• 創(chuàng)建本地庫(kù)的 metadata，createrepo /data/yum/centos/6/x86_64，還有一些參數(shù)可用，比如 -p, pretty xml, -d create sqlite database files
• 配置 apache，修改 /etc/httpd/conf/httpd.conf，修改 DocumentRoot 和 Directory 位置，改為 /data，并啟動(dòng) httpd -k start，也可以使用 chkconfig –level 3 https on，每次開機(jī)啟動(dòng)

客戶端步驟

• 首先要制作安裝 repository 位置的 rpm 包
• 創(chuàng)建文件 haha.repo，放到 /root/rpmbuild/SOURCES 目錄下，這個(gè)是將來 copy 到客戶端的 /etc/yum.repos.d/ 目錄下的配置文件，內(nèi)容為

  [haha]
      name=haha
      baseurl=http://192.168.157.131/yum/centos/$releasever/$basearch/
      enabled=1
      gpgcheck=0

• 再創(chuàng)建文件 build spec 文件，放到 /root/rpmbuild/SOURCES 目錄下，是為了創(chuàng)建 rpm 包用的，haha.spec

  Summary:       haha
      Name:          haha
      Version:       0.1
      Release:       1
      Source0:       haha
      Group:         Applications/Internet
      License:       GPLv2+
      URL:           http://192.168.157.131/yum/
      #BuildRoot:     %{_tmppath}/%{name}-%{version}-root
      BuildArch:     noarch
  
      %description
      The haha yum repo
      #%prep
      #%setup -q
      %install
      mkdir -p $RPM_BUILD_ROOT/etc/yum.repos.d
      install -m 0644 -p %{SOURCE0} $RPM_BUILD_ROOT/etc/yum.repos.d
  
      %clean
      rm -rf ${RPM_BUILD_ROOT}
      %files
      /etc/yum.repos.d/haha.repo

• 使用 rpmbuild -ba haha.spec，做出一個(gè) rpm 包，位置在 /root/rpmbuild/RPMS/noarch 下面
• 制作一次 rpm 后，就可以一直使用了，rpm -ivh xxx.rpm 就可以了

參考了
1. 自建yum源與制作RPM安裝包yum源
2. yum只下載rpm包不自動(dòng)安裝方法
3. Installing Chef Server 0.10 in RHEL 6

stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
java.sql.ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(Integer.MIN_VALUE);

在 Eclipse 中執(zhí)行下面代碼。

        byte[] bytes = new byte[]{-16, -97, -116, -70};

        String s = new String(bytes, "UTF-8");

        System.out.println(s);

結(jié)果打印出了一朵花，呵呵，實(shí)在是太有意思了。

http://en.wikipedia.org/wiki/Category:Unix_signals 1.SIGHUP信號(hào) UNIX中進(jìn)程組織結(jié)構(gòu)為 session (會(huì)話)包含一個(gè)前臺(tái)進(jìn)程組及一個(gè)或多個(gè)后臺(tái)進(jìn)程組，一個(gè)進(jìn)程組包含多個(gè)進(jìn)程。一個(gè)session可能會(huì)有一個(gè)session首進(jìn)程，而一個(gè)session首進(jìn)程可能會(huì)有一個(gè)控制終端。一個(gè)進(jìn)程組可能會(huì)有一個(gè)進(jìn)程組首進(jìn)程。進(jìn)程組首進(jìn)程的進(jìn)程ID與該進(jìn)程組ID相等。這兒是可能會(huì)有，在一定情況之下是沒有的。與終端交互的進(jìn)程是前臺(tái)進(jìn)程，否則便是后臺(tái)進(jìn)程。 SIGHUP會(huì)在以下3種情況下被發(fā)送給相應(yīng)的進(jìn)程： 1、終端關(guān)閉時(shí)，該信號(hào)被發(fā)送到session首進(jìn)程以及作為job提交的進(jìn)程（即用 & 符號(hào)提交的進(jìn)程） 2、session首進(jìn)程退出時(shí)，該信號(hào)被發(fā)送到該session中的前臺(tái)進(jìn)程組中的每一個(gè)進(jìn)程 3、若父進(jìn)程退出導(dǎo)致進(jìn)程組成為孤兒進(jìn)程組，且該進(jìn)程組中有進(jìn)程處于停止?fàn)顟B(tài)（收到SIGSTOP或SIGTSTP信號(hào)），該信號(hào)會(huì)被發(fā)送到該進(jìn)程組中的每一個(gè)進(jìn)程。 系統(tǒng)對(duì)SIGHUP信號(hào)的默認(rèn)處理是終止收到該信號(hào)的進(jìn)程。所以若程序中沒有捕捉該信號(hào)，當(dāng)收到該信號(hào)時(shí)，進(jìn)程就會(huì)退出。 下面觀察幾種因終端關(guān)閉導(dǎo)致進(jìn)程退出的情況，在這兒進(jìn)程退出是因?yàn)槭盏搅薙IGHUP信號(hào)。login shell是session首進(jìn)程。 首先寫一個(gè)測(cè)試程序，代碼如下： #include <stdio.h> #include <signal.h> char **args; void exithandle(int sig) {         printf("%s : sighup received ",args[1]); } int main(int argc,char **argv) {         args = argv;         signal(SIGHUP,exithandle);         pause();        return 0; } 程序中捕捉SIGHUP信號(hào)后打印一條信息，pause()使程序暫停。 編譯后的執(zhí)行文件為sigtest。 1、命 令：sigtest front > tt.txt    操 作：關(guān)閉終端    結(jié) 果：tt.txt文件的內(nèi)容為front : sighup received    原 因: sigtest是前臺(tái)進(jìn)程，終端關(guān)閉后，根據(jù)上面提到的第1種情況，login shell作為session首進(jìn)程，會(huì)收到SIGHUP信號(hào)然后退出。根據(jù)第2種情況，sigtest作為前臺(tái)進(jìn)程，會(huì)收到login shell發(fā)出的SIGHUP信號(hào)。 2、命 令：sigtest back > tt.txt &      操 作：關(guān)閉終端       結(jié) 果：tt.txt文件的內(nèi)容為 back : sighup received       原 因: sigtest是提交的job，根據(jù)上面提到的第1種情況，sigtest會(huì)收到SIGHUP信號(hào)。 3、命 令：寫一個(gè)shell，內(nèi)容為[sigtest &]，然后執(zhí)行該shell       操 作：關(guān)閉終端       結(jié) 果：ps -ef | grep sigtest 會(huì)看到該進(jìn)程還在，tt文件為空       原 因: 執(zhí)行該shell時(shí)，sigtest作為job提交，然后該shell退出，致使sigtest變成了孤兒進(jìn)程，不再是當(dāng)前session的job了，因此sigtest即不是session首進(jìn)程也不是job，不會(huì)收到SIGHUP。同時(shí)孤兒進(jìn)程屬于后臺(tái)進(jìn)程，因此login shell退出后不會(huì)發(fā)送SIGHUP給sigtest，因?yàn)樗粚⒃撔盘?hào)發(fā)送給前臺(tái)進(jìn)程。第3條說過若進(jìn)程組變成孤兒進(jìn)程組的時(shí)候，若有進(jìn)程處于停止?fàn)顟B(tài)，也會(huì)收到SIGHUP信號(hào)，但sigtest沒有處于停止?fàn)顟B(tài)，所以不會(huì)收到SIGHUP信號(hào)。 4、命 令：nohup sigtest > tt       操 作：關(guān)閉終端       結(jié) 果：tt文件為空       原 因: nohup可以防止進(jìn)程收到SIGHUP信號(hào) 至此，我們就清楚了何種情況下終端關(guān)閉后進(jìn)程會(huì)退出，何種情況下不會(huì)退出。 要想終端關(guān)閉后進(jìn)程不退出有以下幾種方法，均為通過shell的方式： 1、編寫shell，內(nèi)容如下        trap "" SIGHUP #該句的作用是屏蔽SIGHUP信號(hào)，trap可以屏蔽很多信號(hào)       sigtest 2、nohup sigtest 可以直接在命令行執(zhí)行，        若想做完該操作后繼續(xù)別的操作，可以 nohup sigtest & 3、編寫shell，內(nèi)容如下        sigtest &        其實(shí)任何將進(jìn)程變?yōu)楣聝哼M(jìn)程的方式都可以，包括fork后父進(jìn)程馬上退出。 2.SIGCHLD信號(hào)        子進(jìn)程死后,會(huì)發(fā)送SIGCHLD信號(hào)給父進(jìn)程。         一個(gè)進(jìn)程在調(diào)用exit命令結(jié)束自己的生命的時(shí)候，其實(shí)它并沒有真正的被銷毀，而是留下一個(gè)稱為僵尸進(jìn)程（Zombie）的數(shù)據(jù)結(jié)構(gòu)（系統(tǒng)調(diào)用exit，它的作用是使進(jìn)程退出，但也僅僅限于將一個(gè)正常的進(jìn)程變成一個(gè)僵尸進(jìn)程，并不能將其完全銷毀）。在Linux進(jìn)程的狀態(tài)中，僵尸進(jìn)程 是非常特殊的一種，它已經(jīng)放棄了幾乎所有內(nèi)存空間，沒有任何可執(zhí)行代碼，也不能被調(diào)度，僅僅在進(jìn)程列表中保留一個(gè)位置，記載該進(jìn)程的退出狀態(tài)等信息供其他進(jìn)程收集，除此之外，僵尸進(jìn)程不再占有任何內(nèi)存空間。它需要它的父進(jìn)程來為它收尸，如果他的父進(jìn)程沒安裝SIGCHLD信號(hào)處理函數(shù)調(diào)用wait或waitpid()等待子進(jìn)程結(jié)束，又沒有顯式忽略該信號(hào)，那么它就一直保持僵尸狀態(tài)，如果這時(shí)父進(jìn)程結(jié)束了，那么init進(jìn)程自動(dòng)會(huì)接手這個(gè)子進(jìn)程，為它收尸，它還是能被清除的。但是如果如果父進(jìn)程是一個(gè)循環(huán)，不會(huì)結(jié)束，那么子進(jìn)程就會(huì)一直保持僵尸狀態(tài)，這就是為什么系統(tǒng)中有時(shí)會(huì)有很多的僵尸進(jìn)程。 2.SIGTERM信號(hào) kill() 可以發(fā) SIGTERM 過去；kill 命令默認(rèn)也使用 SIGTERM 信號(hào)。 SIGTERM 信號(hào)的處理函數(shù)，常見的是用來清理、退出；或者程序可以忽略這個(gè)信號(hào)，以防誤殺。         SIGTERM is the default signal sent to a process by the kill or killall commands. It causes the termination of a process, but unlike the SIGKILLsignal, it can be caught and interpreted (or ignored) by the process. Therefore, SIGTERM is more akin to asking a process to terminate nicely, allowing cleanup and closure of files. For this reason, on many Unix systems during shutdown, init issues SIGTERM to all processes that are not essential to powering off, waits a few seconds, and then issues SIGKILL to forcibly terminate other processes to allow the computer to halt.

$ kill -l

            1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL

            5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE

            9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2

            13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGSTKFLT 17) SIGCHLD

            18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN

            22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ

            26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO

            30) SIGPWR      31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1

            36) SIGRTMIN+2  37) SIGRTMIN+3  38) SIGRTMIN+4  39) SIGRTMIN+5

            40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8  43) SIGRTMIN+9

            44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13

            48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13

            52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9

            56) SIGRTMAX-8  57) SIGRTMAX-7  58) SIGRTMAX-6  59) SIGRTMAX-5

            60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2  63) SIGRTMAX-1

            64) SIGRTMAX

 patch.sh.zip (1 K) 下載次數(shù):103 

轉(zhuǎn)自：http://blog.csdn.net/cafecheng/archive/2009/07/17/4357248.aspx

H2, HSQLDB, DERBY, POSTGRESQL, MYSQL

轉(zhuǎn)自 http://imysql.cn/node/609

作/譯者：吳炳錫，來源：http://imysql.cn　＆　http://imysql.cn/blog/3208　轉(zhuǎn)載請(qǐng)注明作/譯者和出處，并且不能用于商業(yè)用途，違者必究。

介紹：
InnoDB給MySQL提供了具有提交，回滾和崩潰恢復(fù)能力的事務(wù)安全（ACID兼容）存儲(chǔ)引擎。InnoDB鎖定在行級(jí)并且也在SELECT語(yǔ)句提供一個(gè)Oracle風(fēng)格一致的非鎖定讀。這些特色增加了多用戶部署和性能。沒有在InnoDB中擴(kuò)大鎖定的需要，因?yàn)樵贗nnoDB中行級(jí)鎖定適合非常小的空間。InnoDB也支持FOREIGN KEY強(qiáng)制。在SQL查詢中，你可以自由地將InnoDB類型的表與其它MySQL的表的類型混合起來，甚至在同一個(gè)查詢中也可以混合。
Innodb 的創(chuàng)始人：Heikki Tuuri
Heikki Tuuri在Ｉｎｎｏｄｂ的Ｂｕｇ社區(qū)里也是很活躍的，如果遇到Ｂｕｇ也可以直接提到社區(qū)，得到作者的解答。

為什么要學(xué)習(xí)Ｉｎｎｏｄｂ的調(diào)優(yōu)：
目前來說：InnoDB是為Mysql處理巨大數(shù)據(jù)量時(shí)的最大性能設(shè)計(jì)。它的CPU效率可能是任何其它基于磁盤的關(guān)系數(shù)據(jù)庫(kù)引擎所不能匹敵的。在數(shù)據(jù)量大的網(wǎng)站或是應(yīng)用中Innodb是倍受青睞的。
另一方面，在數(shù)據(jù)庫(kù)的復(fù)制操作中Innodb也是能保證master和slave數(shù)據(jù)一致有一定的作用。

參數(shù)調(diào)優(yōu)內(nèi)容：
　　1. 內(nèi)存利用方面
2. 日值控制方面
3.　文件IO分配，空間占用方面
4. 其它相關(guān)參數(shù)

１.內(nèi)存利用方面：
首先介紹一個(gè)Innodb最重要的參數(shù)：
innodb_buffer_pool_size
這個(gè)參數(shù)和MyISAM的key_buffer_size有相似之處，但也是有差別的。這個(gè)參數(shù)主要緩存innodb表的索引，數(shù)據(jù)，插入數(shù)據(jù)時(shí)的緩沖。為Innodb加速優(yōu)化首要參數(shù)。
該參數(shù)分配內(nèi)存的原則：這個(gè)參數(shù)默認(rèn)分配只有8M，可以說是非常小的一個(gè)值。如果是一個(gè)專用ＤＢ服務(wù)器，那么他可以占到內(nèi)存的70%-80%。這個(gè)參數(shù)不能動(dòng)態(tài)更改，所以分配需多考慮。分配過大，會(huì)使Swap占用過多，致使Mysql的查詢特慢。如果你的數(shù)據(jù)比較小，那么可分配是你的數(shù)據(jù)大小＋１０％左右做為這個(gè)參數(shù)的值。例如：數(shù)據(jù)大小為５０Ｍ,那么給這個(gè)值分配innodb_buffer_pool_size＝６４Ｍ
設(shè)置方法：
innodb_buffer_pool_size=4G
這個(gè)參數(shù)分配值的使用情況可以根據(jù)show innodb status\G;中的
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4668764894; 
去確認(rèn)使用情況。

第二個(gè)：
innodb_additional_mem_pool：
作用：用來存放Innodb的內(nèi)部目錄
這個(gè)值不用分配太大，系統(tǒng)可以自動(dòng)調(diào)。不用設(shè)置太高。通常比較大數(shù)據(jù)設(shè)置16Ｍ夠用了，如果表比較多，可以適當(dāng)?shù)脑龃蟆Ｈ绻@個(gè)值自動(dòng)增加，會(huì)在error log有中顯示的。
分配原則：
用show innodb status\G;去查看運(yùn)行中的ＤＢ是什么狀態(tài)（參考BUFFER POOL AND MEMORY段中），然后可以調(diào)整到適當(dāng)?shù)闹怠?br /> ----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 4668764894; in additional pool allocated 16777216
參考：in additional pool allocated 16777216
根據(jù)你的參數(shù)情況，可以適當(dāng)?shù)恼{(diào)整。
設(shè)置方法：
innodb_additional_mem_pool=16M

２.關(guān)于日值方面：
innodb_log_file_size
作用：指定日值的大小
分配原則：幾個(gè)日值成員大小加起來差不多和你的innodb_buffer_pool_size相等。上限為每個(gè)日值上限大小為4G.一般控制在幾個(gè)ＬＯＧ文件相加大小在２Ｇ以內(nèi)為佳。具體情況還需要看你的事務(wù)大小，數(shù)據(jù)大小為依據(jù)。
說明：這個(gè)值分配的大小和數(shù)據(jù)庫(kù)的寫入速度，事務(wù)大小，異常重啟后的恢復(fù)有很大的關(guān)系。
設(shè)置方法：
innodb_log_file_size=256M

innodb_log_files_in_group
作用：指定你有幾個(gè)日值組。
分配原則：　一般我們可以用２－３個(gè)日值組。默認(rèn)為兩個(gè)。
設(shè)置方法：
innodb_log_files_in_group=3

innodb_log_buffer_size：
作用：事務(wù)在內(nèi)存中的緩沖。
分配原則：控制在2-8M.這個(gè)值不用太多的。他里面的內(nèi)存一般一秒鐘寫到磁盤一次。具體寫入方式和你的事務(wù)提交方式有關(guān)。在Ｏｒａｃｌｅ等數(shù)據(jù)庫(kù)了解這個(gè)，一般最大指定為３Ｍ比較合適。
參考：Innodb_os_log_written(show global status 可以拿到)
如果這個(gè)值增長(zhǎng)過快，可以適當(dāng)?shù)脑黾觟nnodb_log_buffer_size
另外如果你需要處理大理的ＴＥＸＴ，或是ＢＬＯＢ字段，可以考慮增加這個(gè)參數(shù)的值。
設(shè)置方法：
innodb_log_buffer_size=3M

innodb_flush_logs_at_trx_commit
作用：控制事務(wù)的提交方式
分配原則：這個(gè)參數(shù)只有３個(gè)值，０，１，２請(qǐng)確認(rèn)一下自已能接受的級(jí)別。默認(rèn)為１，主庫(kù)請(qǐng)不要更改了。
性能更高的可以設(shè)置為０或是２，但會(huì)丟失一秒鐘的事務(wù)。
說明：
這個(gè)參數(shù)的設(shè)置對(duì)Ｉｎｎｏｄｂ的性能有很大的影響，所以在這里給多說明一下。
當(dāng)這個(gè)值為1時(shí)：innodb 的事務(wù)LOG在每次提交后寫入日值文件，并對(duì)日值做刷新到磁盤。這個(gè)可以做到不丟任何一個(gè)事務(wù)。
當(dāng)這個(gè)值為2時(shí)：在每個(gè)提交，日志緩沖被寫到文件，但不對(duì)日志文件做到磁盤操作的刷新,在對(duì)日志文件的刷新在值為2的情況也每秒發(fā)生一次。但需要注意的是，由于進(jìn)程調(diào)用方面的問題，并不能保證每秒１００％的發(fā)生。從而在性能上是最快的。但操作系統(tǒng)崩潰或掉電才會(huì)刪除最后一秒的事務(wù)。
當(dāng)這個(gè)值為0時(shí)：日志緩沖每秒一次地被寫到日志文件，并且對(duì)日志文件做到磁盤操作的刷新，但是在一個(gè)事務(wù)提交不做任何操作。mysqld進(jìn)程的崩潰會(huì)刪除崩潰前最后一秒的事務(wù)。

從以上分析，當(dāng)這個(gè)值不為１時(shí)，可以取得較好的性能，但遇到異常會(huì)有損失，所以需要根據(jù)自已的情況去衡量。

設(shè)置方法：
innodb_flush_logs_at_trx_commit=1

3.　文件IO分配，空間占用方面
innodb_file_per_table
作用：使每個(gè)Innodb的表，有自已獨(dú)立的表空間。如刪除文件后可以回收那部分空間。
分配原則：只有使用不使用。但ＤＢ還需要有一個(gè)公共的表空間。
設(shè)置方法：
innodb_file_per_table=1

innodb_file_io_threads
作用：文件讀寫ＩＯ數(shù)，這個(gè)參數(shù)只在Windows上起作用。在LINUX上只會(huì)等于４
設(shè)置方法：
innodb_file_io_threads=4

innodb_open_files
作用：限制Innodb能打開的表的數(shù)據(jù)。
分配原則：如果庫(kù)里的表特別多的情況，請(qǐng)?jiān)黾舆@個(gè)。這個(gè)值默認(rèn)是３００。
設(shè)置方法：
innodb_open_files=800 
請(qǐng)適當(dāng)?shù)脑黾觮able_cache

4. 其它相關(guān)參數(shù)
這里說明一個(gè)比較重要的參數(shù)：
innodb_flush_method
作用：Ｉｎｎｏｄｂ和系統(tǒng)打交道的一個(gè)ＩＯ模型
分配原則：Windows不用設(shè)置。
Ｕｎｉｘ可以設(shè)置：fsync() or O_SYNC/O_DSYNC
如果系統(tǒng)可以禁止系統(tǒng)的Ｃａｃｈｅ那就把他禁了。
Ｌｉｎｕｘ可以選擇：O_DIRECT 
直接寫入磁盤，禁止系統(tǒng)Ｃａｃｈｅ了
設(shè)置方法：
innodb_flush_method=O_DIRECT

innodb_max_dirty_pages_pct 
作用：控制Innodb的臟頁(yè)在緩沖中在那個(gè)百分比之下，值在范圍1-100,默認(rèn)為90.
這個(gè)參數(shù)的另一個(gè)用處：當(dāng)Ｉｎｎｏｄｂ的內(nèi)存分配過大，致使Ｓｗａｐ占用嚴(yán)重時(shí)，可以適當(dāng)?shù)臏p小調(diào)整這個(gè)值，使達(dá)到Ｓｗａｐ空間釋放出來。建義：這個(gè)值最大在９０％，最小在１５％。太大，緩存中每次更新需要致?lián)Q數(shù)據(jù)頁(yè)太多，太小，放的數(shù)據(jù)頁(yè)太小，更新操作太慢。
設(shè)置方法：
innodb_max_dirty_pages_pct＝90
動(dòng)態(tài)更改需要有Ｓｕｐｅｒ權(quán)限：
set global innodb_max_dirty_pages_pct=50;

總結(jié)：
這里只算是列出了Ｉｎｎｏｄｂ部分的重要參數(shù)，不能認(rèn)為是對(duì)Ｍｙｓｑｌ的整體調(diào)優(yōu)。Ｍｙｓｑｌ的參數(shù)一般分為：全局參數(shù)，具體引擎的參數(shù)。全局參數(shù)方面請(qǐng)參考http://imysql.cn/2007_12_08_optimize_mysql_under_linux yejr的那個(gè)Ｍｙｓｑｌ調(diào)優(yōu)的ＰＰＴ。