40/sec 對500/sec
介紹
由標題驚奇? 很好, 這是遊覽怎樣我們崩裂了可測量性jinx 從處理貧乏40 個紀錄每秒對500 個紀錄每秒。當心, 我們面對的大多問題直接是向前, 因此有經驗的人民也許發現這過剩。
內容
* 1.0 是我們?
1.1 記憶擊中天空
1.2 低處理率
1.3 資料損失:- (
1.4 Mysql 拉下我們
1.5 緩慢的網路客戶
* 2.0 嚮涅磐的路
2.1 控制記憶!
2.2 簡化處理率
2.3 什麼資料損失uh-uh?
2.4 定調的SQL 詢問
2.5 定調的資料庫圖解
2.5 Mysql 幫助我們穩步前進!
2.6 快速地... 快速地網路客戶
* 3.0 底線
我們在哪裡是?
最初地我們有能稱只40 個紀錄/sec 的一個系統。我能甚而回憶討論, 關於"什麼應該是紀錄的理想的率? "。最後我們決定, 40/sec 是理想的率為一個唯一防火牆。如此當我們必須出去, 我們atleast 需要支持3 個防火牆。因此我們決定, 120/sec 會是理想的率。根據資料從我們的competitor(s) 我們走向, 他們能支持在240/sec 附近的結論。我們認為它是好! 照原樣我們的第一發行。由於所有競爭者談論了防火牆的數量他支持了但不是在率。
記憶擊中天空
我們的記憶總擊中天空在512MB! (OutOfMemory 例外) 我們責備了我們不能逃脫為長期的cewolf(s) inmemory 貯藏引起的images.But! 不論是否我們聯絡了客戶或不是我們□去□常擊中天空在兩三幾天最大3-4 天平! 有趣的是, 這是可再生的當我們送了資料在非常高rates(then), 在50/sec 附近。您猜測它權利, 增長的無限的緩衝直到它擊中屋頂。
低處理率
我們處理紀錄以40/sec 的率。我們使用dataobject(s) 大塊更新。但它沒有給期望的速度! 因此我們開始囤積居奇資料在記憶造成囤積居奇記憶!
資料損失:- (
我們在很高速過去常錯過許多packet(s) 。我們似乎有一點資料損失, 但那導致記憶肉豬。在一些扭捏限制緩衝區大小我們開始有平穩的資料損失大約20% 以非常高速率。
Mysql 拉下我們
我們面對困難時期當我們大約進口了140MB 記錄文件。Mysql 開始hog, 機器開始的爬行並且有時它被停止的responding.Above 全部, 我們開始得到deadlock(s) 和交易timeout(s) 。哪些最終減少了系統的快速響應。
緩慢的網路客戶
我們再這裡責備了我們顯示在頁作為瓶頸圖表的數量, 忽略事實有拉下系統的許多其它因素。頁□去□常需要30 秒對裝載為頁與6-8 張圖表和桌在4 天以後在網際網路資料中心。
嚮涅磐的路
控制記憶!
我們設法投入極限在緩衝區大小的10,000, 但它沒有持續長期。主要缺點在設計是, 我們假設, 緩衝大約10000 會滿足, 即我們會是處理紀錄在10,1000 伸手可及的距離緩衝之前。線型原則"某事可能去錯誤它將連同錯誤!" 它變錯誤。我們開始疏鬆資料。我們決定連同一展開文件基於的貯藏的Subsesquently, 資料被傾銷了入展開文件, 會被裝載入資料庫使用"裝載資料infile" 。這比大塊插入物許多時間快速地是通過您也許並且想要對結算離開一些可能的優化以裝載資料infile 的資料庫司機。這解決了我們的增加未加工的紀錄的緩衝區大小的問題。
我們面對的第二個問題是cewolf(s) 增量在記憶貯藏機制。它使用了"貯藏圖像對象在記憶的TransientSessionStorage", 那裡似乎是某一問題在清掃對象, 在rerferences 丟失了以後! 如此我們寫了小"FileStorage" 實施存放圖像對象在地方文件。並且會服務當請求時候進來。而且, 我們並且implmentated 清潔機制對清潔陳舊的images(圖像舊比10mins) 。
我們發現的其它有趣的方面是這裡, 垃圾收集工有低優先級因此對象被創造為各紀錄, 幾乎不被清掃了。這一點算術解釋問題的巨大。每當我們接受我們創造~20 objects(hashmap 的一個日誌紀錄, tokenized 串等) 如此以500/sec 的率為1 秒, 對象的數量是10,000(20*500*1) 。由於重的處理垃圾收集工從未有一次機會對清潔對象。那麼所有我們必須做是較小扭動, 我們分配了"零位" 到對象參考。Voila! 垃圾收集工是從未拷打我猜測; -)
簡化處理率
處理率是在意味的貧乏40/sec 我們能幾乎不承受甚而日誌紀錄的小爆發! 記憶控制給了我們某一solace, 但實際問題是以機敏的過濾器的應用在紀錄。我們有大約20 物產為各個紀錄, 我們曾經尋找所有物產。我們改變了實施到比賽為我們有標準為的那些物產! 而且, 我們並且有記憶洩漏在機敏過濾器處理。我們維護了永遠增長的一個隊列。如此我們必須維護一個展開文件對象傾銷避免re 解析紀錄形成對象! 而且, 我們過去常做尋找比賽行動為每個物產既使當我們沒有安排機敏的標準被配置。
什麼資料損失uh-uh?
一旦我們固定了記憶發布在接受資料即傾銷入展開文件, 我們從未丟失了資料! 除那之外我們必須去除兩三個不需要的索引在未加工的桌中避免天花板當傾銷資料。我們hadd 索引為能有3 可能的價值最大值的專欄。哪些使插入物更慢和實際上不是有用的。
定調的SQL 詢問
您的詢問是您的鑰匙對表現。一旦您開始釘牢問題, 您看見, 您也許甚而必須de 正常化桌。我們做了它! 這一些關鍵learnings:
* 用途"分析桌" 辨認怎麼mysql 詢問運作。這將給予您洞察力為什麼詢問是慢的, 即是否它使用正確索引, 是否它使用桌水平掃瞄等。
* 從未刪除列當您應付巨大的資料按50,000 個紀錄的順序在一張唯一桌中。總嘗試做"下落製表" 儘量。如果它不是可能的, 再設計您的圖解, 是您唯一出口!
* 避免不需要的join(s), 不害怕de 正常化(即複製專欄價值) 避免join(s) 儘量, 他們傾向於拉下您的詢問。一暗藏的好處是事實他們強加樸素在您的詢問。
* 如果您應付大塊資料, 用途"裝載資料infile" 那裡總是二個選擇這裡, 本機和遙控。使用本機如果mysql 和應用是在同樣機器否則用途遙控。
* 設法分裂您的複雜詢問成二次或三次更加簡單的詢問。好處在這種方法是, mysql 資源不hogged 為整個過程。傾向於使用臨時表。而不是使用跨過橫跨5-6 的一次唯一詢問製表。
* 當您應付巨大的相當數量資料, 即您要對proces 對批量法說50,000 個紀錄或更多在一次唯一詢問嘗試使用極限紀錄。這將幫助您稱系統對新高度
* 總使用更小的transaction(s) 代替大那些即跨過橫跨"n" 桌。這把mysql 資源關起來, 也許導致系統遲鈍為簡單的詢問
* 使用join(s) 在專欄以索引或外國鑰匙
* 保證, 詢問從用戶界面有標準或限制。
* 並且保證, 標準專欄被標註
* 不要有數值在sql 標準在行情之內, 因為mysql 做型塑像
* 使用臨時表儘量, 和投下它...
* select/delete 插入物是一把雙重桌鎖... 知道...
* 保重, 您不使mysql 資料庫痛苦以您的更新頻率對資料庫。我們有我們過去常傾銷對資料庫在每300 個紀錄之後的典型的案件。如此當我們開始測試對於500/sec 我們開始看見, mysql 逐字地拖我們下。那是我們意識到typicall 以500/sec 的率那裡是"裝載資料infile" 請求每秒鐘對mysql 資料庫。如此我們必須改變傾銷紀錄在3 分鐘以後而不是300 個紀錄。
定調的資料庫圖解
當您應付巨大的相當數量資料, 總保證, 您分成了您的資料。那是您的路對可測量性。一張唯一桌以言10 lakhs 可能從未稱。當您打算執行詢問為報告。總有桌、未加工的表一個為實際資料和其他集合的二個水平為報告tables(用戶界面詢問!) 的桌總保證, 關於您的報告桌的資料從未增長在極限之外。裝箱您計劃使用Oracle, 您能試驗分成根據標準。但mysql 不幸地不支持那。如此我們將必須做那。維護裡您通常有報頭資訊即製表尋找, 為一套指定的標準時間的階桌在。
* 我們必須走通過我們的資料庫圖解並且我們補充說增加一些索引, 刪除一些和平衡被複製的column(s) 取消昂貴的join(s) 。
* 去今後我們體會那有未加工的桌因為InnoDB 實際上是天花板對系統, 因此我們改變了它到MyISAM
* 我們並且去在程度減少上行數在靜態桌裡介入加入
* 零位在資料庫桌裡似乎導致某一表現擊中, 因此避免他們
* 不要有索引為允許價值的2-3 的專欄
* 相互核對對各個索引的需要在您的桌裡, 他們是昂貴的。如果桌是InnoDB 然後雙檢查他們的需要。由於InnoDB 桌似乎採取大約10-15 計時MyISAM 桌的大小。
* 使用MyISAM 每當有大多數, 或者(選擇或插入物) 詢問的當中一個。如果插入物和精選是然後最好有它作為InnoDB
Mysql 幫助我們穩步前進!
定調您的mysql 伺服器在您優化您的queries/schemas 和您的代碼之後。只您能然後看在表現的可感知的改善。這一些參量進來得心應手:
* 使用將使您的詢問快速地執行的緩衝設備大小-- innodb_buffer_pool_size=64M 為InnoDB 和使用-- 鑰匙bufer size=32M 為MyISAM
* 簡單的詢問開始花些更多時間比被期望。我們實際上困惑了! 我們意識到, mysql 似乎裝載它開始插入任一張桌的索引。如此什麼典型地發生了是, 任一次簡單的詢問對一張桌以5-10 列需要了大約1-2 秒。在進一步分析我們發現了在簡單的詢問之前, "裝載資料infile" 發生。這消失了當我們改變了未加工的桌到MyISAM 類型, 因為緩衝區大小為innodb 和MyISAM 是二種不同配置。
為更加構形的參量看見這裡。
要訣: 開始您的mysql 開始以以下選擇-- 日誌錯誤這將使能錯誤採伐
快速地... 快速地網路客戶
用戶界面是鑰匙對任一個產品, 特別是頁的被察覺的速度更加重要! 這也許進來得心應手解答和learnings 的名單:
* 如果您的資料不改變為言3-5 分鐘, 最好貯藏您的客戶端頁
* 傾向於使用他們給被察覺的堅牢度您的頁的Iframe(s)for 內在圖表等。仍然改善用途Java 語言基於的美滿的裝貨機制。這是某事您也許想要做當您有言3+ 圖表在同樣頁。
* Internet Explorer 顯示整體頁只當所有內容被接受從伺服器。如此它是適當使用iframes 或Java 語言為美滿的裝貨。
* 從未使用CSS 文件的multiple/duplicate 詞條在超文字標記語言頁。Internet Explorer 傾向於裝載各個CSS 文件作為一個分開的詞條和申請在完全頁!
最後結果您的詢問和圖解使系統更慢! 首先修理他們和然後責備資料庫!
參見
* 高性能Mysql
* 詢問表現
* 解釋詢問
* 優選詢問
* InnoDB 定調
* 定調的Mysql
類別: 防火牆分析儀 | 表現打翻這頁是最後更新18:00, 2005 年8月31 日。
- Ramesh-
文章來源: Messaggiamo.Com
Related:
» Seo Elite: New Seo Software!» AntiSpywareBOT
» Reverse Mobile
» Error Nuker
網管得到HTML代碼
加上這條到你的網站！
網站管理員提交你的文章
無須登記！填寫好的表格和你的文章是在 Messaggiamo.Com 目錄！
