1.linux 系統(tǒng)：
1】關(guān)閉文件系統(tǒng)/分區(qū)的atime 選項(xiàng)
Vi /etc/fstab
在對(duì)應(yīng)的分區(qū)項(xiàng)后面添加noatime ,nodiratime
LABEL=/1 / ext3 defaults 1 1
LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2
2】設(shè)置文件句柄４ｋ＋，目前該配置已經(jīng)集成到啟動(dòng)腳本中。
Vi /etc/security/limit.conf
* soft nproc 65536
* hard nproc 65536
* soft nofile 65536
* hard nofile 65536
3】不要使用large vm page （不要使用大內(nèi)存頁選項(xiàng)）
Linux 大內(nèi)存頁參考：http://linuxgazette.net/155/krishnakumar.html
4】用dmesg 查看主機(jī)的信息。
2.linux 文件系統(tǒng)的選擇：
Mongodb 采用預(yù)分配的大文件來存儲(chǔ)數(shù)據(jù),我們推薦
1】ext4
2】xfs
3.內(nèi)核版本：
網(wǎng)絡(luò)上對(duì)2.6.33-31 以及2.6.32 的表現(xiàn)持懷疑度， 而強(qiáng)力推薦2.6.36
4.線程堆棧的尺寸
默認(rèn)的線程堆棧尺寸為10m ，調(diào)整為1m ，已經(jīng)集成在啟動(dòng)腳本中。
項(xiàng)目過程中的總結(jié)與建議
1.大小寫問題
mongodb 是默認(rèn)區(qū)分大小寫的，但是這會(huì)不會(huì)衍生出跟mysql 一樣的問題？（mysql 區(qū)
分大小寫，導(dǎo)致windows 與linux 下的表名，字段名不一致）。
如果無特別用途，建議表名，字段名全部用小寫字母。
2.盡可能的縮短字段名的長度
mongodb 的schema free 導(dǎo)致了每筆數(shù)據(jù)都要存儲(chǔ)他的key 以及屬性，這導(dǎo)致了這些數(shù)
據(jù)的大量冗余。開發(fā)同事也許考慮到，從易讀性出發(fā)設(shè)計(jì)的key 基本比較長，基本都是按
照起字面意思去設(shè)計(jì)的。這導(dǎo)致key 很長。對(duì)應(yīng)的數(shù)據(jù)存儲(chǔ)占用了很大的空間。
必要的時(shí)候，可以考慮建立一個(gè)key 與實(shí)際意義的map 表，盡量降低key 的長度。
示例定義：
// 基本信息
static final String _ID = "_id";
static final String STATUS_CODE = "sc";
// 緩沖
static final String DATE = "date";
static final String MAX_AGE = "age";
// 內(nèi)容
static final String CONTENT = "content";
static final String CONTENT_TYPE = "ctype";
static final String CONTENT_LENGTH = "clen";
static final String ZIP = "zip";
3. mongodb 單表最大索引數(shù)為64
無索引排序的最大數(shù)據(jù)量為4M, 超過則報(bào)錯(cuò)退出。
建議where 條件盡量落在索引字段上，排序字段需要建立索引，索引的使用原則與oracle
mysql 一致，盡量降低索引數(shù)量，索引長度。
mongodb 的查詢每次只能用到一個(gè)索引，對(duì)數(shù)據(jù)的查詢不會(huì)“并發(fā)”執(zhí)行
例如： db.tab.find({'id'=1,'name'=2}) 如果‘id’，‘name' 列上分別有索引
對(duì)查詢效率提升意義不大，如果索引為（'id','name') 則大幅提升效率。
4.mongodb 添加字段
如果添加字段且?guī)в衐efault 值，需要全部數(shù)據(jù)都要修改，這也是設(shè)計(jì)階段需要考慮的
事情，這個(gè)問題的另外一種解法是應(yīng)用代碼里做一次判斷。
5.測試過程的密碼問題
對(duì)于用作數(shù)據(jù)庫使用的Mongodb，在代碼測試階段都應(yīng)加上密碼驗(yàn)證，目前上線階段基
本都會(huì)在密碼驗(yàn)證方面出現(xiàn)問題（做緩存使用的可以不做密碼驗(yàn)證)。
6.數(shù)據(jù)源連接方式
使用連接池模式，盡量減少認(rèn)證帶來的性能額外消耗
建議采用標(biāo)準(zhǔn)的uri 連接方式： mongodb://user:passwd@host:port,host:port/db
7.Mongodb日志量
正常情況下不需要開啟-v 日志選項(xiàng)。
Mongodb 的-v 日志適合在開發(fā)環(huán)境的調(diào)試線上部署不建議采用這個(gè)參數(shù)，目前線上
部署的情況，-v 日志一天也會(huì)有幾個(gè)G 的日志量，去掉這個(gè)參數(shù)，跟數(shù)據(jù)查詢相關(guān)的操作
就不會(huì)記日志了，數(shù)據(jù)庫的內(nèi)部的重要操作還是會(huì)寫日志的。
8.連接數(shù)大小的設(shè)置
Mongodb 驅(qū)動(dòng)程序采用的連接池的方式連接到數(shù)據(jù)庫，目前從觀察到的情況是應(yīng)用一
開啟便根據(jù)變量的設(shè)置，建立全部連接，然后提供給程序使用，并且一旦其中某個(gè)連接
到數(shù)據(jù)庫的訪問失敗，則會(huì)清空整個(gè)連接池到這臺(tái)數(shù)據(jù)庫的連接，并重新建立連接。
而mongodb 對(duì)中斷連接的垃圾清理工作則是懶惰的被動(dòng)清理方式，如果驅(qū)動(dòng)程序端配
置的連接數(shù)過大，一旦發(fā)生重連，則會(huì)導(dǎo)致mongo 端堆積大量的垃圾連接數(shù)據(jù)，導(dǎo)致
主機(jī)資源耗盡。
建議： mongodb 驅(qū)動(dòng)的連接池大小的設(shè)置一般應(yīng)該控制100 以下，一般情況30-50 足
夠支撐應(yīng)用訪問。
9.鎖的問題
Mongodb 對(duì)數(shù)據(jù)庫的訪問全部加鎖，如果是查詢請求則設(shè)置共享鎖，數(shù)據(jù)修改請求，
則設(shè)置全局排他鎖，并且是實(shí)例級(jí)別的排他鎖。并且寫鎖會(huì)阻塞讀請求，如果長時(shí)間持有
寫鎖，會(huì)阻塞整個(gè)實(shí)例的讀請求。
部署建議：
1】一般情況下，建議不同的應(yīng)用不要合用一套示例。
2】如果資源不滿足，需要合用，應(yīng)該具有相同屬性的應(yīng)用合用一套實(shí)例。
例如合同mongo 的應(yīng)用都是讀多寫少，防止一臺(tái)寫多應(yīng)用阻塞讀請求。
10.關(guān)于map/reduce問題
mongodb 對(duì)map/reduce 的支持是單線程的，我們不建議在前臺(tái)使用該功能， group by
是通過map/reduce 實(shí)現(xiàn)的，開發(fā)過程中，要慎用。
11.安全問題
1】Mongodb 運(yùn)行在mongodb 用戶之上，并禁止mongodb 用戶登錄
2】使用Mongodb 自帶的認(rèn)證方法（adduser、auth）限制用戶訪問行為
3】將Mongodb 置于內(nèi)網(wǎng)環(huán)境中
4】Mongodb 必須暴露在外網(wǎng)環(huán)境中的時(shí)候，使用IPTABLES 等網(wǎng)絡(luò)層技術(shù)進(jìn)行防護(hù)
5】網(wǎng)絡(luò)層面內(nèi)容為明文傳輸，可以考慮存儲(chǔ)加密文檔，應(yīng)用端，加解密。
12.性能監(jiān)控
Mongodb 自帶有性能數(shù)據(jù)收集系統(tǒng)
Mongostat 實(shí)時(shí)采集數(shù)據(jù)庫的多項(xiàng)指標(biāo),提供http console 端口號(hào)為應(yīng)用端口號(hào)+1000。
關(guān)注的主要性能指標(biāo)：
1】Faults：顯示Mongodb 每秒頁面故障的數(shù)量，這個(gè)是mongoDB 映射到虛擬地址空間，
而不是物理內(nèi)存，這個(gè)值如果飆高的話，可能意味著機(jī)器沒有足夠的內(nèi)存來
存儲(chǔ)數(shù)據(jù)和索引。
2】Flushes：每秒做了多少次fsync，顯示多少次數(shù)據(jù)被刷新進(jìn)了磁盤
3】locked：寫鎖
4】idx miss：索引未命中比例
5】qr | qw：讀寫鎖的請求隊(duì)列長度。
6】conn： 當(dāng)前已經(jīng)建立的連接數(shù)。
其他命令：
Db.stat()
db.serverStatuse()
Db.collection.stats()
13.碎片問題
Mongodb 數(shù)據(jù)庫如果數(shù)據(jù)修改很頻繁，會(huì)出現(xiàn)比較嚴(yán)重的空間碎片問題，表現(xiàn)在磁盤
文件擴(kuò)張與實(shí)際數(shù)據(jù)量不相符，內(nèi)存不夠用，索引命中率低，查詢效率降低。
碎片整理，目前我們采用的版本沒有太有效的方法。
可以用db.repaireDatabase() 來整理數(shù)據(jù)庫，這個(gè)過程非常的慢
如果是Master-slave 模式則相當(dāng)于執(zhí)行一次主從切換，然后從新建立從庫。
如果是replSet 架構(gòu)可以停掉數(shù)據(jù)庫，然后刪除數(shù)據(jù)目錄，從新從復(fù)制復(fù)制組中全同步數(shù)據(jù)，
這個(gè)時(shí)候要考慮oplog 的尺寸。
一個(gè)大體的步驟：
1.】先調(diào)用rs.freeze(1200),將每個(gè)不想讓它成為primary 的機(jī)器讓它在1200 秒內(nèi)無法成為
primary(這步也可以不做)
2. 】將primary stepDown,不出意外新的primary 會(huì)起來.
3. 】將原primary kill 掉.
4. 】刪掉所有data 數(shù)據(jù)(調(diào)用repair 很慢,真不如干掉重新來)
5. 】再重啟動(dòng)原primary 的進(jìn)程
6. 】以此循環(huán)完成整個(gè)復(fù)制組的全部重建。
14.系統(tǒng)備份：
Mongodb 目前不支持在線備份，只能離線備份。
我們采用的架構(gòu)為replSet 和Master-slave .
基于我們目前的架構(gòu)以及數(shù)據(jù)一致性要求，我們沒有安排相關(guān)的備份系統(tǒng)。
15.應(yīng)用代碼中Mongodb連接問題
在有些應(yīng)用在使用Mongodb 過程中會(huì)存在以下兩個(gè)小問題：
1. 在應(yīng)用啟動(dòng)過程中，應(yīng)用存在要求連接池中所有的連接都建立成功才讓應(yīng)用正
常啟動(dòng)，這種做法不可取，因?yàn)榇嬖诰W(wǎng)絡(luò)問題、Mongodb 拒絕連接或Mongodb 假死情況，如
果沒加外部try catch 做防護(hù)，則Resin 不斷重啟也不能正常啟動(dòng)端口。
2.有些應(yīng)用在使用Mongodb 中連接池配置了safe=true，w=1；這種配置意味著客戶端在
插入數(shù)據(jù)或更新數(shù)據(jù)的時(shí)候，要求mongodb 必須將所更新的數(shù)據(jù)寫入磁盤并返回更新成功
的信息給程序。如果碰上應(yīng)用程序訪問壓力大，mongodb 就會(huì)反應(yīng)遲鈍，并會(huì)發(fā)生假死可能，
針對(duì)此情況，需要評(píng)估數(shù)據(jù)的一致性需求，做出合適調(diào)整。我們一般建議關(guān)閉此選項(xiàng)。
16.補(bǔ)充開發(fā)方面的一些問題
1】skip+limit翻頁，越往后面越慢，有資料說用數(shù)組元素的分頁可以解決，目前還沒
試過，比較靠譜的做法是，先找出上次的id，翻頁的時(shí)候不用skip：
last_row_id = ObjectId(‘....’);
db.activity_stream->find({_id:{$lt: last_row_id },
user_id:20 } ).sort( {_id:-1} ).limit(10);
2】.只有真正需要的字段才select出來
3】.更新的某條數(shù)據(jù)的時(shí)候，先查出來再更新會(huì)減小鎖的時(shí)間
4】.只有返回很少結(jié)果的查詢才用索引，否則會(huì)加載太多數(shù)據(jù)，比沒有用索引還慢
5】.屬性比較多的時(shí)候，建立分層的關(guān)系能夠提高查詢效率，否則每個(gè)記錄都要過一遍
才能找到要的屬性
17.關(guān)于硬件資源的選擇：
虛擬機(jī)可以很好的隔離資源，并可動(dòng)態(tài)的擴(kuò)展。
我們建議mongodb 的部署采用虛擬機(jī)的方式，每個(gè)虛擬機(jī)部署一個(gè)實(shí)例，使各節(jié)點(diǎn)分
散在不同的物理機(jī)上,根據(jù)應(yīng)用的前期預(yù)測，平衡虛擬機(jī)的之間的i/o。