總結本來剛開始按照初次調優的方式進行調優的，結果發現出問題了，原因是查詢與匯出功能的資料量相對較大導致的
jvm調優實踐：記錄初次jvm調優經歷
堆大小設定：-xmx256m -xms256m -xmn96m
嗯，然後就炸了，只能按照實際情況來調整了
這裡就不多做說明了，這裡的堆大小設定目的是足夠大，因此設定了 1024m，新生代依然佔 3/8，經計算為 384m
為了養成習慣，這裡就不用 jconsole 視覺化介面進行檢視了，直接走命令
jps：檢視程序
jmap -histo:live ：列印存貨物件，同時會觸發 fgc
jstat -gc 1000：列印記憶體使用情況，1000 ms 輸出一次
先進行一次 fgc，開始列印後，就直接去執行會產生大量記憶體的功能
首先根據上面的記錄，能看到這麼兩條記錄
從這裡可以看出，這是第一次呼叫時產生了大量記憶體，並且沒有發生gc，因此我們可以通過這裡計算出這一次請求大致產生了多大的記憶體
後一次新生代的使用量 - 上一次新生代的使用率
37288.6 + 106008.1 - 4538.7 = 138,758 kb = 135.5m
也就是說我這次請求產生了 135.5m 的記憶體
如果s 區相同年齡（每次gc年齡+1）物件的總大小 > s 區總大小的 50%，這些物件以及年齡大於這些物件的物件全部移動到 o 區。（只要觸發 minorgc 該條件處理過程必然觸發）
上面這個是 cms 物件晉公升老年代的規則
根據 e 區與 s 區 佔比 8 ：1，我們很容易算出，哪怕在 1024m 堆的情況下，預設每塊 s 區的大小為 38.4m，哪怕通過調整 e 區與 s 區的佔比，我們也很難讓這麼大的內存在 s 區中被容納，除非給予非常大的記憶體。但很明顯針對乙個不常用的匯出功能，這麼做明顯是一種浪費，極其的不合適。
調整目標：
保證老年代的空間足夠容納大物件，並且保證不會觸發 concurrent mode failure
老年代大小：512 x 5/8 = 320m
此時每個大物件佔老年代佔比：135.5 / 320 = 42%
由此可以判斷，512m 時候只夠容納兩個這樣的大物件，說簡單點極容易出現老年代不夠的情況，因而觸發 concurrent mode failure 導致 fgc，應盡可能避免
老年代大小：1024 x 5/8 = 640m
此時每個大物件佔老年代佔比：135.5 / 640 = 21%
由於可知，當堆為 1024m 時，只要我保證每次老年代只要達到 70% 就進行 gc，就不會導致這個大物件從而觸發 fgc
調整 vm 引數：
由於調優做的不多，如果**有不準確或者不對的麻煩指出
中間臨時改變了調優目標，由此可見，調優這東西確實看經驗
剩下的就配置好後打包上線測試，看看整體運**況了
關於 ORACLE 大資料量操作 的調優
由於系統進入到壓力測試階段，需要準備大量資料來模擬測試環境，其中就牽涉到一些大的資料量的操作。以下是一些心得。1.如果需要對乙個大資料量的表進行全表更新，那是非常耗時的。那麼此時不如使用 create table temp as select b.x,b.y,b.z from table b 來代替...
大資料集群調優
場景1 在datanode開始工作 通電 的時候，會上報本地的資料塊給namenode的客戶端進行註冊，這時候客戶端個數比較關鍵，如果太少，datanode在連線namenode的時候會出現總是超時或者連線被拒絕 如果設定太大，則記憶體開銷會增大，造成不必要的浪費，最終可能導致記憶體溢位。引數 df...
php 大資料量匯出
之前的正常匯出，幾萬條資料就把記憶體擠爆了，優化了一下匯出方式，記憶體無壓力匯出速度槓槓的 會員時手機匯出 public function user outputexcel else count count data num 0 f null foreach this getcounts count...