1. 首頁
  2. 問答
  3. 在EC2 debian實例上優化Solr 4

在EC2 debian實例上優化Solr 4

2013-05-13 43 views
1

我的Solr 4實例很慢，我不知道爲什麼。 我試圖修改JVM，Tomcat6和Solr 4的配置，按照 的順序來優化性能，每秒查詢作爲關鍵指標。 目前我正在使用Debian squeeze在EC2 small層上運行，但如果需要的話可以準備切換到Ubuntu。在EC2 debian實例上優化Solr 4

我的用例沒有什麼特別之處。指數很小。查詢包括適量的工會（例如10個），加上面子，但我不認爲這很不尋常。

我的理解是，這些地區可能需要的調整：

  • 配置JVM垃圾回收進度和內存分配（「GC調優是一個精確的藝術形式」，ref）
  • 其他JVM設置
  • Solr的查詢結果緩存，過濾器高速緩存，文件緩存設置
  • Solr的自動預熱設置

有許多的方法來監測Solr的表現：

但是這些方法都沒有說明哪些設置需要調整，並且我沒有通過詳盡的設置列表來了解這些步驟的指南，這些設置可能會提高性能。我回顧了以下幾頁（one,two,three,four），並且迄今爲止經歷了幾輪試驗和錯誤而沒有改進。

問題：

  • 如何告訴JVM使用所有的2 GB內存上的小EC2實例？
  • 如何調試和優化JVM垃圾收集？
  • 我如何知道何時I/O限制（如新的EBS IOPS定價）是問題？
  • 使用下面的NewRelic示例等數字，如何檢測問題行爲以及如何處理解決方案。

答案：

  • 我找鏈接，良好的文檔建立和優化的Solr 4，從DevOps的或服務器管理員的角度（沒有索引或應用程序設計）。
  • 我正在尋找最可能導致問題的catalina.sh，solrconfig.xml，solr.xml（其他？）中的頂級故障點。
  • 或者您認爲解決問題的任何提示。

enter image description here enter image description here

來源

2013-05-13 ted.strauss

+0

相關：http://stackoverflow.com/questions/12079269/speeding-up-solr-search?rq=1 – 2013-05-13 20:13:42

回答

5

首先，你不應該集中在開關你的Linux版本。不同的分佈可能會帶來一些變化，但考慮到您提供的信息，沒有任何證據表明這些變化可能很重要。

您提到了很多優化的可能性，這可能是壓倒性的。只有當你證明問題在於你的堆棧的特定部分時，你才應該考慮調整區域。

JVM堆大小調整

可以使用參數-mx1700m給予的RAM的JVM最大1.7GB的。熱點可能不需要它，所以如果你的堆容量沒有達到那個數量，不要感到驚訝。

您應該將最小堆大小設置爲較小值，以便Hotspot可以優化其內存使用量。例如，要將最小堆大小設置爲128MB，請使用-mx128m。

垃圾收集

從你說的話，你有有限的硬件（1核心爲1.2GHz最大值，見this page）

M1小型實例

  • 1.7吉布內存
  • 1 EC2計算單元（1個虛擬核心，帶1個EC2計算單元）
  • ...

一個EC2計算單元提供1.0-1.2 GHz的2007的Opteron或2007至強處理器的等效CPU容量

因此，使用低延遲GC（CMS）不會有任何好處。由於您只有一個內核，因此無法與您的應用程序同時運行。您應該使用-XX:+UseParallelGC -XX:+UseParallelOldGC切換到吞吐量GC。

GC真的有問題嗎？

要回答這個問題，您需要打開GC日誌記錄。這是查看GC暫停是否對您的應用程序響應時間負責的唯一方法。你應該打開-Xloggc:gc.log -XX:+PrintGCDetails。

但我不認爲問題出在這裏。

這是硬件問題嗎？

要回答這個問題，您需要監視資源利用率（磁盤I/O，網絡I/O，內存使用率，CPU使用率）。你有很多工具可以做到這一點，包括top，free,vmstat, iostat,mpstat,ifstat，...

如果您發現其中一些資源飽和，那麼您需要一個更大的EC2實例。

它是軟件問題嗎？

在你的統計中，文檔緩存命中率和過濾器緩存命中率是健康的。但是，我認爲查詢結果緩存命中率非常低。這意味着很多查詢操作。

您應該監視查詢執行時間。根據該值，您可能需要增加緩存大小或調整查詢，以便減少時間。

更多鏈接

希望幫助！

來源

2013-05-14 15:10:19

+0

非常感謝！ – 2013-05-15 12:34:55

相關問題

 相關問題