Analytics and Automation Software : Cisco Data Virtualization

CIS из устранения проблем ошибок памяти

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает начальный процесс, который используется для ответа на ошибки Из памяти (OOM) на Сервере информации о Cisco (CIS).

Внесенный Брэдом Шао и Сурешем Кумаром Венкэтесаном, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • CIS
  • Ошибки OOM

Используемые компоненты

Сведения в этом документе основываются на Версии v6.2.0 CIS.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Устраните неполадки ошибок OOM

Эти шаги предоставляют обзор начального процесса, который необходимо использовать при получении ошибки OOM:

  • Определите запрос преступника, если возможный и проверяют воспроизводимость.
  • Определите любые утечки памяти сервера (неисправимая память, которая была использована ранее).
  • Определите, является ли ваш запрос причиной или жертвой исчерпания памяти.

Просмотрите график памяти

Если существенная зеленая линия (общая память) колеблется около колпачка памяти аппарата, в то время как никакие активные запросы в настоящее время не работают, и желтая линия (управляемая память) около нижней части, могла бы быть утечка.

Поиск повторяющихся попыток выполнить автоматический сбор мусора

В cs_server.log файле существуют множественные последовательные записи, которые кажутся подобными этому:

-------------------------------------------------------------------------------
INFO 2012-09-25 13:44:02.816 -0400 RequestManager - Performing GC because there
is not enough Java memory to start a request. GC took 7709 ms.
INFO 2012-09-25 13:44:10.520 -0400 RequestManager - Performing GC because there
is not enough Java memory to start a request. GC took 7704 ms.
INFO 2012-09-25 13:44:26.202 -0400 RequestManager - Performing GC because there
is not enough Java memory to start a request. GC took 7768 ms.
-------------------------------------------------------------------------------

Это указывает, что память неисправима, когда Сбор мусора (GC) не в состоянии быть эффективным каждый раз, когда Виртуальная машина java (JVM) решает, что пора выполнить GC, и GC повторяет себя.

Используйте свободную неиспользованную кнопку Memory

При использовании Свободной Неиспользованной кнопки Memory она выполняет ручной GC нашего JVM. Если общая память не в состоянии восстанавливаться в графике, могла бы быть утечка, или JVM решил, что это не должно освобождать некоторую память.

Удалите накопленные завершенные запросы

Можно удалить накопленные Завершенные Запросы, которые появляются в консоли Запросов менеджера киностудии. Текущие завершенные элементы строки, особенно те от клиентов мыла, которые используют экстраординарную память иногда, держатся на ту память, пока это не очищено от показа.

Определите проблему

Оцените время, когда началась утечка. Если часть графика памяти, который содержит запуск утечки (восходящее повышение, которое никогда не восстанавливается) рулоны мимо диаграммы, вы могли бы быть в состоянии найти расчетное время возникновения от cs_server_status.log файла. Для достижения этого файла перейдите к <CIS_INSTALL_DIRECTORY>> журналы> cs_server_status.log. По умолчанию снимок различных функционирований сервера пишется в этот журнал каждые 60 минут. Для отслеживания полной кучи в использовании просмотрите этот раздел журнала статуса:

----------------
| Memory Dump |
----------------

Поиск какое-то время, когда размер кучи внезапно повышается и никогда не падает. Это дает вам оценку того, когда событие преступника имело место. Существует также снимок запросов, которые работают в то время, который мог бы дать представление о возможной проблеме. При определении периода, когда память в большой степени использована, можно искать раздел в журнале статуса, который содержит этот заголовок:

----------------
| Top Requests |
----------------

Это - список запросов, которые используют большую часть памяти в то время. можно также видеть, что это отобразилось в консоли Запросов Studio.

На этом этапе вы, возможно, должны были бы просто перезапустить сервер и начать контролировать график памяти периодически для наблюдения за подозрительным использованием памяти.

Примечание: Когда OOM обнаружен, в v6.2 автоматически произведен файл дампа кучи, названный журналами / / "javapid <*> .hprof. Когда память была истощена, при просмотре этого файла указывает он. Кроме того, можно передать этот файл к Группе по поддержке Cisco так, чтобы это могло быть проанализировано для подсказок.

Иногда нет никакой утечки, но просто необычно с большой загрузкой памяти запрос, который вызывает ошибку. Обычно память является восстанавливаемой после сбоев запроса, и вы в состоянии продолжить большинство других действий. Ищите скачок и падение графика памяти.

Если ошибка OOM вызвана одиночным идентифицируемым запросом, необходимо пересмотреть кучу Java и конфигурацию памяти. Повысьте полную кучу настолько же высоко, как ваше ОЗУ поддерживает приблизительно до 1.3 ГБ для Операционных систем на 32 бита (ОС), или кроме того для ОС на 64 бита. Рассмотрите соответствующий параметр для Памяти На Запрос во избежание ситуаций, где одиночный пользователь использует всю память сервера за счет всего сообщества пользователей.

Если ваш запрос должен законно использовать большой объем памяти из-за его характера, затем рассмотреть добавление {ОПЦИЯ FORCE_DISK} к оператору SELECT запроса, чтобы предотвратить истощение памяти и защитить другие запросы из памяти исчерпание. Это не только приносит пользу другим запросам пользователя в то время, но и это фактически улучшает производительность интенсивного запроса. Это вызвано тем, что это сразу движется потоком к диску, когда обработано и не предпринимает попытки сначала использовать память, и затем отступает, когда это находит потребность двигаться потоком к диску вместо этого.



Document ID: 118032