Solr總是使用超過90％的物理內存(Solr always use more than 90% of physical memory)

我在solr索引中存儲了300000個文檔。 并使用4GB RAM作為solr服務器。 但它消耗超過90％的物理內存。 所以我把我的數據轉移到一臺有16 GB RAM的新服務器上。 再次solr消耗超過90％的內存。 我不知道如何解決這個問題。 我使用了默認的MMapDirectory和solr版本4.2.0。 請解釋一下，如果您有任何解決方案或原因。

I have 300000 documents stored in solr index. And used 4GB RAM for solr server. But It consumes more than 90% of physical memory. So I moved to my data to a new server which has 16 GB RAM. Again solr consumes more than 90% memory. I don't know how to resolve this issue. I used default MMapDirectory and solr version 4.2.0. Explain me if you have any solution or the reason for this.

原文：https://stackoverflow.com/questions/22149296

更新時間：2019-11-05 12:05

最滿意答案

MMapDirectory嘗試盡可能多地使用操作系統內存(OS Cache)，這是正常行為，它會嘗試將整個索引加載到內存中(如果可用)。 事實上，這是一件好事。 由于這些內存是可用的，它會嘗試使用它。 如果同一臺計算機上的另一個應用程序需要更多，則操作系統將為其釋放它。 這就是為什么Solr / Lucene的查詢速度快一個數量級的原因，因為大多數調用服務器的內存都是以內存(取決于內存大小)而不是磁盤。

JVM內存是不同的東西，它可以被控制，只有正在運行的查詢響應對象和某些緩存項使用JVM內存。 所以JVM的大小可以根據數字請求和緩存條目進行配置。

MMapDirectory tries to use the OS memory (OS Cache) to the full as much as possible this is normal behaviour, it will try to load the entire index into memory if available. In fact, it is a good thing. Since these memory is available it will try to use it. If another application in the same machine demands more, OS will release it for it. This is one the reason why Solr/Lucene the queries are order of magnitude fast, as most of the call to server ends up memory (depending on the size memory) rather than disk.

JVM memory is a different thing, it can be controlled, only working query response objects and certain cache entries use JVM memory. So JVM size can be configured based on number request and cache entries.

相關問答

MMapDirectory嘗試盡可能多地使用操作系統內存(OS Cache)，這是正常行為，它會嘗試將整個索引加載到內存中(如果可用)。 事實上，這是一件好事。 由于這些內存是可用的，它會嘗試使用它。 如果同一臺計算機上的另一個應用程序需要更多，則操作系統將為其釋放它。 這就是為什么Solr / Lucene的查詢速度快一個數量級的原因，因為大多數調用服務器的內存都是以內存(取決于內存大小)而不是磁盤。 JVM內存是不同的東西，它可以被控制，只有正在運行的查詢響應對象和某些緩存項使用JVM內存。

...

暴露給用戶空間應用程序的所有地址(包括mtrace()顯示的地址mtrace()都是虛擬內存地址。 All addresses exposed to userspace applications, including those shown by mtrace(), are virtual memory addresses.

默認情況下，solr 4.3將mmap索引到內存中，您可以嘗試其他DirectoryFactory，例如SimpleFSDirectoryFactory。 請參閱solrconfig.xml中的DirectoryFactory部分。 By default, solr 4.3 will mmap index into memory, you may try other DirectoryFactory, such as SimpleFSDirectoryFactory. See DirectoryF

...

wmic os get FreeVirtualMemory, FreePhysicalMemory, FreeVirtualMemory,MaxProcessMemorySize,TotalVisibleMemorySize,TotalVirtualMemorySize

比systeminfo工作得更快 wmic os get FreeVirtualMemory, FreePhysicalMemory, FreeVirtualMemory,MaxProcessMemorySize,TotalVi

...

Solr顯然在這個數字中加入了“buff / cache”。 如果將其添加到“已使用”，則獲得98％。 記憶是可以回收的，所以你不應該擔心。 操作系統只是盡可能地使用RAM進行磁盤緩存。 Solr apparently includes "buff/cache" into that number. If you add it to "used" you get 98%. That memory is reclaimable, so you shouldn't be worried. Operati

...

虛擬內存本質上(在實際意義上)與物理內存相同，只是擴展到系統的磁盤驅動器以進行緩存(請參閱分頁文件)。 由于它位于磁盤上，因此訪問速度要慢得多，因為在讀取數據之前需要將數據從磁盤“交換”到物理內存中。 如果程序有內存泄漏，它將填滿(或至少達到程序可用內存的限制。) 您可以使用top來檢查消耗大量內存的進程。 如果內存量在異常速率的程序中繼續增長，那么這可能是內存泄漏的指示。 使用像valgrind這樣的程序可以更容易識別： http ： //en.wikipedia.org/wiki/Valgri

...

9GB由您添加的8GB執行程序內存作為參數組成， spark.yarn.executor.memoryOverhead設置為.1 ，因此容器的總內存為spark.yarn.executor.memoryOverhead + (spark.yarn.executor.memoryOverhead * spark.yarn.executor.memoryOverhead)這是8GB + (.1 * 8GB) ≈ 9GB 。 您可以使用一個執行程序來運行整個過程，但這需要很長時間。 要理解這一點，您需要

...

你自己看： JVM無法為堆獲取足夠的內存并退出。 我認為沒有辦法讓JVM使用特定數量的內存進行分頁，但您可以使用： -XX:+|-UseLargePages - 用于大頁面支持 和-XXLargePageSizeInBytes= - 用于指定大頁面的大小。 請查看http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/java.html See for yourself: JVM fails in getting enough

...

總結

以上是生活随笔為你收集整理的服务器物理内存总是九十几,Solr总是使用超过90％的物理内存(Solr always use more than 90% of physical memory)...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。