我們在 Ubuntu 20.04 上運行 Elasticsearch 8.2。機器有 4GB 記憶體。由于我們仍在測驗中，因此索引了不到 1MB 的資料。但是，Elasticsearch 會在幾個小時后被作業系統殺死。
Jun 24 01:53:27 industry-new kernel: [1443806.368450] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom
,task_memcg=/system.slice/elasticsearch.service,task=java,pid=1366207,uid=112
Jun 24 01:53:27 industry-new kernel: [1443806.368567] Out of memory: Killed process 1366207 (java) total-vm:4775580kB, anon-rss:2350732kB, f
ile-rss:0kB, shmem-rss:0kB, UID:112 pgtables:4976kB oom_score_adj:0
Jun 24 01:53:27 industry-new kernel: [1443806.495334] oom_reaper: reaped process 1366207 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0
kB
我們嘗試通過在 /etc/elasticsearch/jvm.options.d 中創建一個名為 es.options 的檔案來限制堆大小并設定：
--Xms2g
--Xmx2g
有了這個設定，我們甚至無法重新啟動 elasticsearch - 它超時了。
請問有什么關于如何解決這些殺戮的建議嗎？
uj5u.com熱心網友回復：
您需要在jvm.optionsnotes.options檔案中添加以下行，并且該檔案需要位于configElasticsearch 的檔案夾中。
--Xms2g
--Xmx2g
注意：更多資訊請參考jvm options 官方檔案。
uj5u.com熱心網友回復：
能夠通過將 2 個 Xm 值分別設定為 1g 來“解決”這個問題。這是在一臺有 4GB 記憶體的機器上，另外只運行一個由 Gunicorn 提供的小型 python 實體。Elasticsearch 中快取的資料不超過 20MB，但如果不檢查，最終會因為記憶體而被殺死。即使在當前設定下，Elastic 仍不斷占用不到 2GB 的 RAM。為什么我什至無法開始理解。正如我在我的問題中提到的，每臺機器都有 4GB 的記憶體，所以需要將你的 jvm 分配設定為不超過 1gb 以防止 oom 殺死。
我認為我們在升級之前使用的是 Elasticsearch 4 或 5，它在 1GB 機器上運行良好。Elasticsearch 在索引時也棄用了“type”變數，這使得跟蹤索引中的實際內容變得不必要地復雜。Python 和 Ubuntu 的 Elastic 檔案只能被描述為混亂和不完整。我懷疑我們是否會向未來的任何客戶推薦 Elasticsearch。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/495660.html