當天是周五，下午對方說需要進行上線推廣了。於是就直接上線了。下班之後回到家，突然接到阿里的賬戶餘額提醒。由於伺服器是採用的按量計費，頻寬直接是拉到最大的 100m，所以賬戶餘額瘋狂扣費。這可不得了，畢竟這個專案預算有限，就當機立斷，把按量改為頻寬，把頻寬限制降低。降低之後，接到訊息說，很多使用者打不開頁面。進入控制台一看，我靠，頻寬滿了。
然後進行緊急的頻寬公升級到 20m，發現還是瞬間被拉滿。公升級到 50m，依舊如此。想了一下，頻寬公升級不划算，畢竟公升級到 100m，依舊無法解決載入緩慢問題。於是就開始排查載入緩慢的原因。
經過測試排查，發現是由於該專案中，使用到了乙個背景** 5m，乙個字型 4m，都是甲方提供要求的。這兩個檔案載入實在是太大了，並且專案中的靜態資源也都比較大，影響載入速度。可這大半夜的也聯絡不到甲方的美工啊，我也不會壓縮（試了一下，把透明壓縮黑了 ?），沒辦法，先上個 cdn，全站加速。所有資源檔案 js、、字型、bgm 全部用上 cdn。瞬間，頁面載入就流暢了，bgm 也不卡頓了。終於可以安心的睡下了。
第二天出去玩，在路上都是時刻盯著手機，看著這個流量飛速的跑，還是有點虛。畢竟地主家也沒有餘糧啊。想著回去怎麼優化。
cdn 流量也是要燒錢的啊。檢視熱門資源是哪些
除了上面的一些 bgm、字型檔案外，就是一些。於是就開始進行壓縮。將部分小檔案流量重新導到伺服器，畢竟現在伺服器頻寬有 50m。
處理前頻寬峰值達到了 365m，處理之後頻寬峰值直接下降到了 68m
部分流量導回伺服器後，伺服器頻寬占用 35m，也算是不浪費伺服器頻寬了。
前端訪問流暢之後，似乎訪問量增加了還是這麼的，後台壓力激增。伺服器 cpu 占用暴漲，直接 100%。進入 mysql，執行show processlist;命令，發現大量的查詢語句，呼叫的是乙個儲存過程。由於前端功能需要，所以封裝了乙個儲存過程。應該是這個儲存過程的鍋，於是對查詢增加索引。優化分頁的時機，先進行分頁然後在進行相關資料查詢處理。cpu 問題暫時解決了。
活動的最後兩天，訪問突然增加，伺服器 cpu 再次滿了。依然是 mysql 的鍋。前端乙個統計介面，頻繁查詢統計，加上資料量太大。於是手動給後台增加了乙個快取（專案起初沒計畫使用快取）。手動實現乙個快取，資料快取一分鐘，然後過期重新進入資料庫查詢。乍一看沒什麼問題，就提上去了。後面經過觀察發現，隔一分鐘 cpu 就要瘋一次，雖然不是直接跑滿，但是也是跑到了六七十。應該是快取的問題，設計快取的時候沒考慮快取過期時，有多少查詢落到資料庫。由於只做了時候過期判斷。導致資料過期的一瞬間，大量查詢落入資料，快取擊穿了。由於單機服務，就給查詢操作加了鎖，進行二次判斷。
ok，問題解決。基本伺服器 cpu 占用在 30 左右，資料庫 cpu 占用在維持在個位數。
本次問題產生的原因，首先是對於使用者量的判斷不準確，以及前端資源的處理。導致伺服器頻寬被占用完。經過了一系列的折騰、優化，算是基本扛住了。高併發並非只是對於後端介面來說的，前端也是需要處理的。後端介面併發高，可能對應的前端頁面訪問量也是非常巨大的，流量的增加，阻塞伺服器，直接影響前端使用者體驗。所以前端開發，使用的資源檔案要盡量小。伺服器支撐不住，可以上 cdn。後端介面上，需要考慮的就非常多了，業務流程，資料處理，資料庫端的處理等等，都要提前考慮。建議上線前進行壓力測試。
ORACLE 使用超過2G記憶體
在http blog.chinaunix.net u1 50863 showart 411877.html海鷗大哥的部落格上看見這個帖子，覺得很有用。保留下來日後仔細研究。他人的成果不敢據為己有，特此宣告下。伺服器 hpdl 580g 2 雙cpu 6g記憶體 win2003 enterprise ...
fopen開啟2G以上大檔案
fopen開啟2g以上的檔案，是無法開啟的，我估計是跟32bit有關係，跟記憶體大小有關係。網上說的一些方法 1 用fopen64 2 undef file offset bits define file offset bits 64 include include 3 在makefile編譯選項裡...
linux下操作大於2G檔案
1 包含所有標頭檔案以前，先定義這些巨集 ifndef use file offset64 define use file offset64 endif ifndef use largefile64 define use largefile64 endif ifndef largefile64 so...