2012-04-04 280 views
0

我的任務是調查內部Web應用程序出現性能問題的原因。MySQL放大或縮小?

Web應用程序本身是用PHP編寫的,部分是用Perl編寫的,而且我們有一個MySQL數據庫,這是我認爲性能命中源正在發生的地方。

我們有大約400個系統的用戶,其中大部分用戶分佈在不同的時區,所以一般情況下,任何時候最多隻能有30個用戶在線。性能問題已經在我們身上蹣跚而行,特別是在數據庫不斷增長的過去一年。

該系統運行在一臺32位debian服務器上 - 6GB RAM,帶有8個2.4GHz Intel CPU。這對於手頭的工作可能不夠重要。但是,即使在我是唯一在線用戶的情況下,頁面加載時間仍然可能很慢。

我試圖確定是否需要放大或縮小。首先,我想知道我們的硬件如何處理對它的要求。其次,是否值得擴展並創建一些複製從服務器來平衡負載。

在互聯網上有很多工具可用 - 可能有點太多調查。任何人都可以推薦任何工具,可以提供一些分析/性能監測,可以幫助我在我的追求。

非常感謝, NS

+1

不可否認,我對Debian幾乎一無所知,但是不應該使用64位操作系統來使用超過4 GB或RAM? – 2012-04-04 18:23:35

+0

我認爲這取決於它是否是啓用PAE的內核。 – nnichols 2012-04-04 18:46:28

回答

4

你的減速似乎與數據有關而不是數字的併發用戶

適當索引的查詢往往會隨着數據量的對數擴展 - 也就是說,數據翻倍會使查詢時間增加一些常量C,再次由同一個C重複數據,再次由相同的C等重複一次。 ...在你知道它之前,你有大量的數據,但你的查詢只是一個較慢。

如果slow-d在你的情況下,你自己並不是漸進的(即它與數據量成線性關係,或者更糟),這可能表明查詢效果不佳。在這個問題投入更多鐵將推遲,但除非你有無限的預算,你必須在某個時候以實際解決的根本原因:

  1. 措施上的實際數據的查詢性能,以確定慢查詢。
  2. 檢查可能改進的執行計劃。
  3. 如有必要,請了解indexing, clustering, covering和其他表演技巧。
  4. 最後,將這些知識應用於您在步驟(1)和(2)中確定的查詢。

如果沒有其他的幫助,想想你的數據模型。有時,一個「完美」的規範化模型並不是最好的模型,因此可能需要一點司法的非規範化。

2

,如果你有預算僅僅是扔它一些更多的鐵易(懶惰)的方式。

更好的方法是,在決定在哪裏或如何擴展之前,將確定瓶頸。每頁加載速度都很慢嗎?或只是特定的網頁?如果只是幾頁,那麼投資一個分析器(對於PHP來說,xDebug和Zend Debugger都可以執行分析)。我也會(如果你還沒有)投資一個儘可能與實時系統類似的測試系統來運行診斷。

你也可以看看收集一些統計數據;無論是在服務器級別的程序,如sar(from the sysstat package,也在數據庫級別(你是否運行了慢速查詢日誌?)。

+3

是的,如果只有一個用戶速度很慢,縮放並不是問題。修復性能是。 – ceejayoz 2012-04-04 17:19:12

+0

感謝您的輸入。我們在過去的一兩年中使用過sar,但它並沒有特別向我們介紹MySQL的性能。 我會研究一些你的建議並回復你。 非常感謝, – nonshatter 2012-04-04 19:57:59