2014-03-26 44 views
2

我的數據庫非常受cpu限制,我無法找到問題的根本原因。我目前有兩個應用程序服務器,每個應用程序服務器都通過Rails API通過ruby-pg gem連接到PostgreSQL。這兩個應用程序服務器還有sidekiq運行後臺作業,並且我有一些支持服務器通過sidekiq處理來自全國訂閱源的新帖子。如果我內存不足,解決方案看起來會很簡單。任何一般的想法,爲什麼我受到CPU限制?爲什麼我的PostgreSQL服務器cpu受到限制?

數據庫規格:

  • Rackspace的8GB性能層級雲VM(8GB RAM,8倍核心CPU,SSD)
  • 的Debian 7喘息Linux操作系統
  • 的PostgreSQL 9.1在PostGIS擴展

可能的問題:

  • PostgreSQL 9.1的索引不好

數據庫有近10GB的索引。我將把我的數據庫升級到PostgreSQL版本> = 9.2。在9.2版中,引入了僅索引掃描。

  • 連接太多

在postgresql.conf,我已經設置爲 '500' 最大連接。通常全天只使用175個連接,但在高峯時段,sidekiq任務會將當前連接數增加到350個。建議使用8GB服務器實例建議多少個連接?

  • 偶像連接

當我看一看在PSQL控制檯和pg_stat_activity,我看到sidekiq是留下了很多空閒連接。這些連接可能導致CPU通貨膨脹嗎?該修補程序是否存在於api或sidekiq中?

  • 需要一個更強大的服務器

也許沒有一個bug。我可能需要簡單地增加服務器實例。如果我受到記憶限制,這又會更有意義。但是,這兩個應用程序服務器和3個支持sidekiq服務器都是4gb性能層實例。本質上,與數據庫交互的服務器合併的數據庫資源是其兩倍多。這應該甚麼?

其他問題:

  • 我應該使用什麼工具/技術來解決這個問題?
  • postgresql.conf中有關cpu使用情況的任何基本設置?
  • 是否有任何與rails,sidekiq或pg gem相關的已知問題可能是促成因素? (我沒有看到任何未解決的問題。)
  • 是否有任何一般的CPU使用情況的postgreSQL準則?
  • 任何其他想法可能有助於我的搜索想法?
+0

CPU會去postgres,ruby,sidekiq或其他東西嗎? 「頂」顯示你什麼?如果postgres,它是哪個進程? (使用頂部的'c'來顯示所謂的命令行。) – jjanes

+0

是的,它是postgres。 –

+0

22882 postgres 20 0 2238m 2.0g 2.0g S 21.4 25.7 16:58.12 postgres:xxadmin mysite_production 192.xxx.x.xx(41009)空閒交易 –

回答

8

您正在使用大量併發連接。 PostgreSQL將浪費大量時間在家務管理和雜耍併發查詢上。所有的併發工作都將爭取CPU和緩衝區空間,這會對自旋鎖產生重大爭奪,並且通常都是一團糟。

在8核心計算機上,如果主要受CPU限制,則應該不會有超過20個有效連接。如果你是I/O有限的,你可以更高,但350是荒謬的。

如果可能的話,將PgBouncer置於PostgreSQL實例之前的事務池模式中,這樣查詢就會排隊並快速並行執行,而不是慢速並行執行。

請參閱number of database connections (Pg wiki)

此外,PostGIS可能非常重CPU。它有時需要做非常複雜的計算。我建議使用auto_explain模塊來記錄長時間運行的查詢,並使用pg_stat_statements/pg_stat_plans來記錄什麼是佔用資源。檢查這些查詢,看看他們是否需要改進。您的idle in transaction會話也必須處理。根據他們爲什麼閒置以及他們是否擁有交易ID,他們可能會導致嚴重的表膨脹。他們還在PostgreSQL中創建了不必要的信號開銷,因爲它必須與後端進行更多的協調,這些後端正在積極做事。最後,自己開放的交易數量增加了一些內部管家業務的成本。

所以。如果減少連接數量,將數據庫的性能提高,將PgBouncer置於事務池模式,並修復這些空閒連接。

+0

乾杯,隊友。最佳答案我已經在stackoverflow上。 –

2

最有可能是CPU受限,因爲你的工作需要大量的CPU。 :)

9.1在索引上通常不好。所有版本都可能存在一些特定問題,而這些問題可能會因版本而異。

當您受到IO限制時,僅索引掃描通常會帶來好處。我不會抱有太大的希望,因爲這是你的靈丹妙藥。

350個連接肯定沒有幫助,但可能也不是很有害。但是當它們有害時,它可能是徹頭徹尾的災難。正確的值更多取決於內核的數量,而不是RAM的數量。如果很容易抑制邊框連接,即使無法證明它有幫助,也要做到這一點。

如果連接只是空閒的,而不是空閒的事務,那麼它們可能不是非常有害的,但是也有一些情況是可以的。這與連接數量幾乎相同。

您從top顯示的連接在事務中處於空閒狀態。這個狀態不應該佔用太多的CPU,所以這可能意味着它正在快速循環語句,並且恰好在它們之間捕捉到它。但是您沒有說明top中有多少類似的行,如果它只是表示您的代碼沒有同時運行,而是有8個CPU中的7個被浪費了。

關於數據庫服務器與其他服務器,如果數據庫基本上是限制,用更大的錘子敲打它是沒有幫助的。在計算完成的地方往往有一定的靈活性。如果你可以讓應用程序服務器執行更多的數據庫計算,並讓數據庫專注於ACID問題,那就太好了。但除了你以外,沒有人能夠知道這是可能的還是可行的。

我的第一站是使用pg_stat_statements來查看哪些SQL語句花費最多的時間。也許只是給最慢/最頻繁的查詢添加一個索引會使問題神奇地消失。

+0

他們是交易中的偶像,頂部有20個相同的列表。 –

+0

22882 postgres 20 0 2238m 2.0g 2.0g S 21.4 25.7 16:58.12 postgres:xxadmin mysite_production 192.xxx.x.xx(41009)在交易中閒置 –

相關問題