5

Вопрос по java, performance, solr – Solr (JVM) пик каждый час

РЕШИТЬ

В нашем случае проблема заключалась в том, что для SuggestRequestHandler (requestHandler name = "/предложить") теперь лицевой лимит установлен: 10 Также было несколько запросов для каждого отдельного запроса предложения, сделанного приложением. Почему это привело к (просто) часовому пику, пока не совсем понятно ...

Спасибо всем за советы и помощь - я признателен!

Каждый полный час (12:00, 13:00, 14:00, ..., 20:00, 21:00, 22:00, 23:00) у нашего процесса Solr / Java есть пик - что означает процесс Java где Solr работает в 3 раза увеличивает нагрузку на процессор и время отклика, которое обычно требуется msecs, до 9 секунд. Всегда на 2 - 3 минуты и только при наличии трафика на нашем сайте (есть приложение php, которое вызывает Java). Кронд был полностью отключен, но проблема продолжалась каждый час. И в основном я думаю, что мы попробовали почти каждую комбинацию GC и памяти (а может и нет?)

У кого-то есть идеи, почему это происходит - вот некоторые подробности:

  • Система: 32 ГБ ОЗУ, 24 ядра (в основном используется совместно с php-fpm, но даже изолирована только для решения той же проблемы)
  • Solr версия 3.6 (на Jetty - временно также Glassfish)
  • ОС: RHEL 5.7
  • Многоядерная настройка (4 индекса с каждыми 2 ядрами)

Использованные обработчики (solrconfig.xml):











(также тестируется без репликации и пинга)

Используемые фильтры:













Размер индекса: ~ 100 МБ (на самом деле даже немного меньше)

Текущие параметры Java:

JAVA_OPTS="-Xmx4096m -Xms4096m -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:MaxPermSize=128m -XX:+DisableExplicitGC -Dsun.rmi.dgc.server.gcInterval=300000 -Dsun.rmi.dgc.client.gcInterval=300000 -XX:NewRatio=1 -Xloggc:/shop/logs/live/solr/gc.log -verbose:gc -XX:+PrintGCDateStamps"

Те же параметры, но с 1024, 2048, 8192 и 12 ГБне поможет вообще.

Другие попробуют:

JAVA_OPTS="-server -Xmx2048m -XX:MaxPermSize=128m -XX:+UseParNewGC     -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC"

Другие попробуют:

JAVA_OPTS="-Xmx2048m -Xms2048m -XX:+UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:MaxPermSize=128m -XX:+DisableExplicitGC -Djava.util.logging.config.file=/opt/solr-jetty/etc/jetty-logging.properties"

Вот выдержка из gc.log (такой проблемы с полным часом):

2013-03-03T19:59:04.157-0300: 8087.754: [GC 3433559K->1788819K(3914560K), 0.0358190 secs]
2013-03-03T19:59:12.031-0300: 8095.628: [GC 3437075K->1792088K(3914560K), 0.0365830 secs]
2013-03-03T19:59:22.419-0300: 8106.016: [GC 3440344K->1803266K(3914560K), 0.0422040 secs]
2013-03-03T19:59:29.044-0300: 8112.641: [GC 3451522K->1815743K(3914560K), 0.0439870 secs]
2013-03-03T19:59:37.002-0300: 8120.599: [GC 3463999K->1821601K(3914560K), 0.0378990 secs]
2013-03-03T19:59:45.468-0300: 8129.065: [GC 3469857K->1822911K(3914560K), 0.0386720 secs]
2013-03-03T19:59:53.750-0300: 8137.347: [GC 3471167K->1829299K(3914560K), 0.0405040 secs]
2013-03-03T20:00:01.829-0300: 8145.426: [GC 3477555K->1832046K(3914560K), 0.0383070 secs]
2013-03-03T20:00:06.327-0300: 8149.924: [GC 3480302K->1831567K(3914560K), 0.0450550 secs]
2013-03-03T20:00:11.123-0300: 8154.719: [GC 3479823K->1843283K(3914560K), 0.0401710 secs]
2013-03-03T20:00:14.360-0300: 8157.957: [GC 3491539K->1854079K(3914560K), 0.0368560 secs]
2013-03-03T20:00:17.419-0300: 8161.015: [GC 3502335K->1855130K(3914560K), 0.0375530 secs]
2013-03-03T20:00:20.006-0300: 8163.603: [GC 3503386K->1861867K(3914560K), 0.0413470 secs]
2013-03-03T20:00:22.726-0300: 8166.323: [GC 3510123K->1870292K(3914560K), 0.0360600 secs]
2013-03-03T20:00:25.420-0300: 8169.017: [GC 3518548K->1872701K(3914560K), 0.0326970 secs]
2013-03-03T20:00:27.138-0300: 8170.735: [GC 3520957K->1873446K(3914560K), 0.0381430 secs]
2013-03-03T20:00:28.748-0300: 8172.345: [GC 3521702K->1889189K(3914560K), 0.0379160 secs]
2013-03-03T20:00:30.404-0300: 8174.001: [GC 3537445K->1887193K(3914560K), 0.0407670 secs]
2013-03-03T20:00:32.713-0300: 8176.309: [GC 3535449K->1892863K(3914560K), 0.0366880 secs]
2013-03-03T20:00:34.791-0300: 8178.388: [GC 3541119K->1899095K(3914560K), 0.0398270 secs]
2013-03-03T20:00:36.533-0300: 8180.129: [GC 3547351K->1910071K(3914560K), 0.0373960 secs]
2013-03-03T20:00:39.037-0300: 8182.634: [GC 3558327K->1904198K(3914560K), 0.0393020 secs]
2013-03-03T20:00:41.548-0300: 8185.144: [GC 3552454K->1912352K(3914560K), 0.0444060 secs]
2013-03-03T20:00:43.771-0300: 8187.368: [GC 3560608K->1919304K(3914560K), 0.0427220 secs]
2013-03-03T20:00:47.411-0300: 8191.008: [GC 3566354K->1918102K(3914560K), 0.0418150 secs]
2013-03-03T20:00:50.925-0300: 8194.522: [GC 3564290K->1930888K(3914560K), 0.0414700 secs]
2013-03-03T20:00:52.991-0300: 8196.588: [GC 3579144K->1933251K(3914560K), 0.0349600 secs]
2013-03-03T20:00:53.027-0300: 8196.624: [GC 1939697K(3914560K), 0.0256300 secs]
2013-03-03T20:00:54.208-0300: 8197.804: [GC 2780505K(3914560K), 0.1424860 secs]
2013-03-03T20:00:55.684-0300: 8199.281: [GC 3029503K->1389766K(3914560K), 0.0370380 secs]
2013-03-03T20:00:58.289-0300: 8201.886: [GC 2213458K->570843K(3914560K), 0.0413220 secs]
2013-03-03T20:01:00.672-0300: 8204.268: [GC 1962741K->319619K(3914560K), 0.0410840 secs]
2013-03-03T20:01:02.906-0300: 8206.503: [GC 1966833K->319605K(3914560K), 0.0453730 secs]
2013-03-03T20:01:06.861-0300: 8210.458: [GC 1967861K->330864K(3914560K), 0.0425570 secs]
2013-03-03T20:01:10.067-0300: 8213.664: [GC 1979120K->336541K(3914560K), 0.0479380 secs]
2013-03-03T20:01:12.587-0300: 8216.184: [GC 1984797K->343203K(3914560K), 0.0376810 secs]

Также всего 2 записи (около 1 дня) больше 1 секунды: grep -oP ", [1-9] .. *? Secs] $ " /shop/logs/live/solr/gc.log, 1,1727270 секунд], 1,0390840 секунд]

У кого-нибудь есть идеи или уже было это явление с solr / jvm?

<span>Вы можете использовать инструменты, упомянутые в<a href="http://stackoverflow.com/questions/930915/which-java-thread-is-hogging-the-cpu/932937#932937">эта почта</a> выявить проблемные темы.</span>

Mar 04, 2013, 11:18 AMотericson

<span>Я должен сказать, что я неЯ не понимаю, что является решением этой проблемы. @ GeorgBuske вы можете объяснить более подробно?</span>

Jul 24, 2013, 12:51 PMотCosimo

<span>@GeorgBuske проверьте эту ссылку:<a href="http://stackoverflow.com/questions/2787591/solr-autocommit-and-autooptimize">stackoverflow.com/questions/2787591/...</a></span>

Mar 04, 2013, 11:06 AMотKonstantin V. Salikhov

<span>@ ItayMoav-Malimovka даже без PingRequst (для этого также отключен haproxy), DumpRequest и ReplicationRquestHandler (отключена основная репликация):</span>

Mar 04, 2013, 3:49 PMотGeorg Buske

2ответа

0

если размер индекса составляет всего 100 МБ, и проблема связана с GC, я бы начал с:

  1. уменьшив -Xmx до значения менее 1024, начните примерно с 256 м и посмотрите,достаточно
  2. не используйте -XX в начале
  3. использовать последний JDK
5

Дон»Не верьте своим журналам GC, если вы не включите -XX: + PrintGCApplicationStoppedTime в опциях. Подозреваю их даже тогда. Есть паузы и части пауз, которые могут быть очень длинными и не сообщаться, если вы не включите этот флаг. Например. Я'мы видели паузы, вызванные случайным длительным счетным циклом, который занимал 15 секунд, чтобы достичь безопасной точки, где GC сообщал только о 0,08 секундах части паузы, где он фактически выполнял некоторую работу. Есть также много пауз, причины которых не считаются частью "GC» и таким образом может остаться незамеченным флагами регистрации GC.

Вы можете попробовать добавитьjHiccup как агент, чтобы сообщать о наблюдаемой паузе / сбое / остановке / икоте, а не полагаться на честность журналов JVM. Если он показывает мультисекундные глюки, то выВы узнаете, что ваша JVM приостановлена. Если это показывает бесперебойную работу JVM, то вы знаете, как посмотреть на другие части конфигурации.

RelatedQuestions