“凍結”谷歌計算引擎實例 PostgreSQL

Question

我們在 Google 計算引擎上運行了幾個 Debian 實例和 PostgreSQL，最近我們已經看到了以下問題的多次出現。

實例突然變得無響應。 我們不能 ssh 它，我們不能連接到數據庫。 使用 telegraf 的內部監控在此期間也沒有運行，沒有收集到監控數據。

Google 對 CPU 活動的監控顯示該期間的使用率非常低。 GCP 日志不顯示任何遷移，實際上根本不顯示任何內容。 此外，所有內部日志（例如 postgresql 日志、系統日志、來自定期 cronjobs 的日志）也顯示出相同的差距。 看起來該實例在那段時間有點凍結。 到目前為止，我們只注意到 PostgreSQL 個實例，因為這些實例被大量使用。

實例運行這些操作系統和 PG 的變體：

• Debian 9 PG 11.9
• Debian 9 PG 10.13

這些事件通常需要 10-15 分鍾，但在一個案例中需要 1:20 小時。 在事件結束時，一些 PG 進程被 OOM 殺手殺死，但在事件開始之前數據庫上的活動通常相對較低，CPU 使用率和 memory 使用率也是如此。 所以它看起來更像是一個實例在再次啟動時資源有限？ 如果可能的話……

知道這些問題的原因是什么或者我們應該尋找什么嗎？ 正如我提到的，在事件發生期間，Debian 的內部日志中通常沒有任何信息。

更新：為避免誤解 - 有問題的實例是運行在 N1-highmen-8 機器（8 個 CPU 和 52 GB 內存）和 5 TB SSD 上的數據倉庫數據庫。 或者從 inte.net 收集指標的數據庫——定制機器 20 個 CPU，90 GB RAM 和 3 TB SSD。 所有軟件都是最新的。

更新 2：系統日志、kern.log 和消息在實例無響應期間的時間間隔內均未顯示任何內容。 事件發生后，telegraf 立即記錄了 CPU 上的巨大平均負載，但實際上 CPU 使用率非常低，谷歌監控顯示在整個事件期間 CPU 使用率非常低。 同樣在事件結束后，postgresql 進程中的一個立即被 OOM 殺手殺死，導致數據庫 go 進入恢復模式。

至於 PG work_mem 參數 - 實例收集指標（20 個 CPU 90 GB RAM，3 TB SSD）使用 8MB - 它僅插入數據但通常運行 500 - 1000 個連接。

第二個實例是數據倉庫分析數據庫並使用 work_mem 128MB，因為較低的數字會導致大多數查詢的查詢計划非常糟糕，並且通常只運行 10 - 30 個連接。

在兩個數據庫上發生事件之前，沒有異常數量的連接。

更新 3：分析數據庫今天發生了幾起具有相同特征的小事件。 在最后一個過程中，我們從 GCP GUI 停止了實例，並在幾分鍾后再次啟動它。 也許它導致遷移到不同的硬件。 由於此操作實例運行正常。

Answer 1

我遇到了類似的問題，但是在 GCP 中有一個 MySQL 實例，第一個問題與我使用的 VM 實例的類型有關，我在這個 VM 實例上有一個 f1-micro 機器類型，突然我無法訪問ssh。由於這種類型的VM Instance只有memory的0.6GB，所以很快就用完了memory，我把它換成了默認值的e2-medium，這次解決了我的問題。 由於實例不在 memory 中，實例中的服務開始失敗，這是我無法訪問我的實例的原因。

另一次我又開始了類似的問題，但這一次，問題是磁盤，我只有 10 GB 並且有一個進程填滿了我的磁盤，當一個分區空間不足時，實例又開始失敗了。 我只調整了我的磁盤大小，現在我的實例磁盤是 20GB 並且工作正常。

話雖如此，我建議根據您的方便增加資源以提高性能，因為出現您描述的問題是一個很好的指標，表明您現有的機器類型不適合您在該實例上運行的工作負載。

如果你的情況和我一樣，你可以更改機器類型來調整你的 memory 並且你可以按照這些任務的后續步驟，請訪問以下鏈接以獲取更多信息。

更改機器類型

1.- Go 到VM 實例頁面。

2.- 在“名稱”列中，單擊您的實例。

3. 在實例詳細信息頁面中，完成以下步驟：

   a) 如果您尚未停止實例，請單擊停止按鈕以停止該實例。

   b) 實例停止后，點擊頁面頂部的編輯按鈕。

   c) 在 Machine configuration 部分下，select 您要使用的機器類型，或創建自定義機器類型以僅增加 Memory。

   d) 保存您的更改並重新啟動您的 VM 實例。

您可以按照本指南或使用以下命令調整磁盤大小：

gcloud compute disks resize DISK_NAME --size DISK_SIZE

或者使用控制台：

1. Go 到磁盤頁面以查看項目中的區域永久性磁盤列表。
2. 單擊要調整大小的磁盤的名稱。
3. 在磁盤詳細信息頁面上，單擊編輯。
4. 在“大小”字段中，輸入磁盤的新大小。
5. 單擊“保存”將更改應用到磁盤。

調整磁盤大小后，必須調整文件系統的大小，以便操作系統可以訪問額外的空間。

注意：請勿將引導磁盤的大小調整為超過 2 TB，因為這是限制。

編輯1

您提到當實例被凍結時，日志不會顯示有關該問題的信息。 您是否嘗試使用 kernel 日志？ 我認為它可以提供有關此問題的大量診斷信息。

對於 Debian，此日志應位於以下路徑中：

/var/log/kern.log

消息日志也可以提供幫助

/var/log/messages

您可以在此鏈接中獲取有關日志的更多信息。

此外，我認為這可能是 PostgreSQL 配置問題，例如您可以查看“work_mem”，此參數指定內部排序操作使用的 memory 的數量和寫入臨時磁盤文件之前的 hash 表。 默認值是四兆字節 (4MB)。

您可以咨詢此URL以獲取更多信息。

我還找到了一篇很好的文章，解釋了如何為數據倉庫使用配置 PostgreSQL

另一種選擇可能是 kernel 進程負責識別可以調出的 memory。 您可以將流程配置為更頻繁地檢查較小的塊。

此鏈接更好地解釋了此配置。

此外，據我所知，數據倉庫服務器會消耗大量資源，因此最好檢查您的實例是否有足夠的資源來滿足您的工作負載。

編輯2

我找到了一篇描述類似問題的文章，它說：

當您消耗的 memory 多於計算機上可用的數量時，您可以開始在 Postgres 日志中看到out of memory錯誤，或者在更糟糕的情況下，OOM 殺手可以開始隨機終止正在運行的進程以釋放 memory 。 Postgres 中的 memory 錯誤只是您正在運行的查詢的錯誤，而 Linux 中的 OOM 殺手開始殺死正在運行的進程，在某些情況下甚至可能包括 Postgres 本身。

這是他們給出的建議。

當您看到out of memory錯誤時，您要么想要通過升級到更大的實例來增加機器本身的整體 RAM，要么想要減少 work_mem 使用的work_mem的數量。 是的，您沒看錯：內存不足時，最好減少work_mem而不是增加，因為這是每個進程可以消耗的 memory 的數量，而太多的操作正在利用 memory。

你可以在這里看到這篇文章“Configuring memory for Postgres”的完整解釋，它可能會幫助你解決這個問題。