Диагностика Java в стиле IBM: Часть 1. Знакомство со средствами диагностики и мониторинга IBM для Java: Dump Analyzer

Нахождение первопричин проблем в больших файлах дампов

Сложность Java™-приложений постоянно увеличивается. В результате диагностика проблем в этих приложениях становится нетривиальной задачей и может потребовать интенсивной работы со сторонней сервис-компанией. Полезный указатель в нужном направлении может помочь сэкономить время и деньги. IBM Dump Analyzer for Java - это инструмент, выполняющий базовый анализ форматированного дампа системы и создающий краткий отчет, показывающий, в каком направлении надо двигаться дальше.

Эта статья знакомит с инструментом IBM Dump Analyzer for Java (анализатор дампов для Java) и предоставляет базовую информацию о типах проблем, которые этот инструмент может диагностировать. В ней объясняется архитектура, на которой построен IBM DA for Java, и представлены некоторые идеи о будущем развитии этого инструмента.

Элен Бикен, программист, IBM

Д-р Элен Бикен (Helen Beeken) - программист, разрабатывающий инструментарий RAS в IBM Java Technology Centre. До присоединения к нынешней команде она работала в проектах с открытым кодом AspectJ и AJDT Eclipse и участвовала в нагрузочном тестировании больших ИТ-систем.



Дэниел Джулин, программист, IBM

Дэниел Джулин (Daniel Julin) имеет 20-летний опыт в разработки и решения проблем сложных online-систем. Как технический руководитель WebSphere Serviceability Team, в настоящее время он помогает команде сформулировать и реализовать коллекцию инструментов и приемов для определения проблем в сервере приложений WebSphere Application Server и максимизировать эффективность поддержки IBM. Иногда он напрямую помогает службе поддержки в разрешении различных критических ситуаций у заказчиков.



Джули Стелли, программист, IBM

Джули Стелли (Julie Stalley) - программист, работающий в команде Java RAS Tooling в Херсли. Она поступила на работу в IBM в 1996 году и до перехода в Херсли в 2001 году пять лет занималась разработкой крупного клиент/серверного приложения. После этого она работала над библиотеками Java-классов, специализируясь на вводе-выводе, сетевом взаимодействии и XML.



Мартин Троттер, программист, IBM

Мартин Троттер (Martin Trotter) работает с Java-платформой почти с момента ее появления. Он много занимался Java VM и сборщиками мусора. Сейчас он работает над усовершенствованием инструментария для диагностики проблем в Java VM.



19.09.2008

Язык Java стал доминирующим в разработке ПО, поэтому очень важным аспектом становится надежность виртуальной Java-машины (Java virtual machine - VM). Обычно VM - весьма надежная программа, но тем не менее во время исполнения в силу различных причин случаются сбои. Изредка эти причины обусловлены ошибками в самой JVM, однако в большинстве случаев они вызваны ошибками или неправильной конфигурацией в стеке ПО, расположенном над VM, например, в сервере приложений IBM® WebSphere®, или в самом приложении.

Сложность стека ПО для стандартного проекта по мере развития информационных технологий увеличивается, что ведет к увеличению сложностей для разработчиков, пытающихся найти источник проблем. В сложной среде объем информации, с помощью которой приходится диагностировать проблему, может быть колоссальным. В промышленной среде могут иметь место Java-куча объемом в несколько гигабайт, сотни потоков, тысячи загрузчиков классов, десятки тысяч классов и огромное количество объектов.

IBM Dump Analyzer for Java (далее Dump Analyzer или DA) - это расширяемая инфраструктура, дающая способ выхода из этой дилеммы. DA доступен для внутренних пользователей IBM и внешних пользователей для расследования проблем при работе с IBM Developer Kit for the Java Platform (IBM SDK) (комплектом разработчика для Java платформы от IBM). Он исследует отформатированный системный дамп с помощью т.н. анализаторов (каждый анализатор задает дампу собственный вопрос) и связывает результаты вместе посредством сценария, создавая краткий отчет об анализе. В первых двух версиях DA может готовить отчеты с результатами четырех типов:

Об этой серии

В серии Диагностика Java в стиле IBM рассматриваются новые инструменты IBM, которые могут быть полезны для решения проблем Java-приложений и повышения их производительности. В каждой статье содержится новая полезная информация.

Авторы статей этой серии входят в новую команду, создающую инструменты для решения проблем в Java-приложениях. Авторы обладают знаниями из разных областей и привносят в команду различные умения и области специализации.

При появлении вопросов или комментариев к статьям связывайтесь с авторами индивидуально.

  • переполнение памяти
  • обнаружение взаимоблокировки
  • завершение работы VM из-за сигнала (в результате внутренней ошибки или ошибки Java-приложения/промежуточного ПО)
  • требуется дальнейшее исследование

Каждый из первых трех пунктов может быть привязан к проблемам определенных типов в VM, которые описаны далее в этой статье.

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

Краткий обзор типов проблем VM

Существует много причин, которые могут привести к сбою в VM во время работы, и каждый тип сбоя требует отдельного подхода для диагностики. Прежде чем перейти к детальному рассмотрению работы с DA, стоит изучить различные типы проблем и подходы к их решению.

Проблемы с переполнением памяти

VM может прекратить работу, если у нее закончится память - память в Java-куче или память, связанная с платформой и используемая VM для хранения стеков потоков, информации о классах, кода, подготовленного JIT-компилятором, графических элементов и других артефактов для взаимодействия с нижележащей операционной системой.

Диагностировать такие проблемы может быть очень сложно, так как выделение памяти, приведшее к сбою, само по себе скорее всего не является причиной. Может быть, какая-нибудь большая коллекция неконтролируемо разрасталась до такой степени, что VM полностью не исчерпала лимит доступного пространства в куче. Обычно приходится исследовать содержимое кучи и сравнивать мгновенные снимки состояния кучи, выполненные в различные моменты времени, выявляя быстро растущие коллекции.

Взаимоблокировка

Взаимоблокировка (deadlock) - это состояние, в котором два или более процесса ожидают, что другой процесс освободит доступ к ресурсу. Поток, владеющий ресурсом, таким как объект-монитор, не может получить уникальные права на другой ресурс, потому что второй поток владеет ими и одновременно пытается получить уникальные права на ресурс, принадлежащий первому потоку. Такие сбои часто проявляются как проблемы с производительностью. Их обычно достаточно просто диагностировать, исследовав состояние потоков и ресурсов, которыми они владеют.

Внутренние ошибки

Внутренние ошибки могут быть вызваны различными проблемами:

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

Ошибки в Java-приложении или промежуточном ПО

На данный момент DA работает с ошибками, которые происходят на уровне самой виртуальной машины, но этот же набор инструментов можно использовать для диагностики различных ошибок и некорректного поведения Java-приложения или промежуточного ПО, работающего в VM. Подобные ошибки могут иметь различные причины, они обычно вытекают из ошибок в коде приложения или промежуточного ПО либо неправильного использования или конфигурирования параметров JVM. Они обычно диагностируются исследованием состояния различных структур данных в приложении или промежуточном ПО, чтобы определить, какой аспект этого состояния является некорректным.


Современные подходы к диагностике проблем

Без инструмента, подобного DA, процесс диагностики проблемы обычно начинается с изучения артефактов, созданных VM в момент сбоя. Обычно это:

  • дамп пространства процесса (дамп системы или core файл)
  • дамп Java-кучи (heapdump)
  • мгновенный срез Java-процесса (файл Javacore)
  • трассировочный файл, показывающий фрагменты истории исполнения

Обычно эти артефакты исследуются индивидуально с помощью специализированных программ для каждого конкретного формата. Процесс определения проблемы обычно состоит в исследовании вручную всей доступной информации. По мере того как объем данных возрастает, этот процесс занимает все больше и больше времени и становится все более специализированной работой. В результате клиенты обычно не хотят выполнять анализ самостоятельно и полагаются на поставщика VM или промежуточного ПО, но большинство фиксируемых проблем обычно находятся в приложении, конфигурации или среде, и не требуют никаких изменений в самой VM или промежуточном ПО. В идеальном случае возможности для диагностики, доступные клиентам, должны быть таковы, чтобы поставщику ПО или промежуточного ПО отправлялись только уникальные проблемы, требующие подобных изменений. Другие проблемы могут быть диагностированы автоматизированным процессом, использующим соответствующие артефакты, произведенные VM.


Обзор Dump Analyzer

DA - это инструмент, основанный на технологии DTFJ (Diagnostic Tooling Framework for Java - инфраструктура диагностических инструментов для Java), про которую еще будет рассказано в этой статье, и предназначенный для анализа дампов системы и поиска проблем различных типов. Этот инструмент состоит из небольших аналитических модулей, которые рассматривают отдельные данные из дампа и определяют наличие конкретной проблемы, например, взаимоблокировки. Эта схема позволяет легко обеспечить добавление новых возможностей и может быть настроена для поиска определенных проблем.

Инструмент работает на двух уровнях:

  • Каждый специализированный модуль анализа пытается диагностировать проблему одного определенного типа и подготовить четкое описание найденной проблемы.
  • Если продиагностировать проблему не удается, каждый модуль для анализа готовит более длинный отчет об одном конкретном аспекте состояния системы. Этот отчет может быть использован экспертом при диагностике проблемы, возможно вместе с другой информацией.

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

Ход процесса анализа:

  1. Инструмент загружает данные дампа, выбранного пользователем, создавая образ для последующего анализа.
  2. Пользователь выбирает один или несколько аналитических модулей, которые будут применены к образу. Если пользователь не выбирает конкретный анализатор, запускается сценарий по умолчанию.
  3. Запускаются модули анализа.
  4. Каждый модуль либо возвращает информацию, которая используется для управления дальнейшим проведением анализа, или генерирует информацию для отчета.
  5. Когда все модули завершают свое исполнение, отчет форматируется в текстовый или HTML-документ.

Как уже говорилось, если пользователь не запрашивает конкретные модули для анализа, то инструмент запускает сценарий по умолчанию (general.sml), который запускает набор анализаторов, проверяющих несколько стандартных типов проблем. Если проблемы этих типов не обнаружены, сценарий вызывает отчет по умолчанию, который выводит общую информацию о состоянии VM на момент, когда был создан дамп.

Далее в этой статье будет показан пример использования DA и обзор некоторых нестандартных модулей для анализа, которые можно выбрать.


Подготовка к использованию Dump Analyzer

Все, что требуется для запуска DA - это отформатированный дамп системы. Дамп системы генерируется по умолчанию, когда происходит аварийная ситуация с VM; однако VM можно настроить так, чтобы дамп создавался и при других негативных ситуациях или по запросу пользователя (дополнительную информацию см. в ссылках Diagnostic Guides в разделе Ресурсы).

Для форматирования дампа системы его нужно обработать инструментом jextract. Делать это нужно с той же VM и на том же компьютере, где был создан дамп, просто введя в командной строке:

jextract "corefilename"

На VM уровня 1.4.2 эта команда создаст файл.sdff; на виртуальной машине версии 5.0 или выше будет создан файл .dmp.zip. Отметим, что на разных платформах могут быть различные параметры, контролирующие формат дампа, получаемого на уровне операционной системы. В частности, это может привести к тому, что дамп системы будет урезан, что помешает DA произвести полезный анализ. Наиболее стандартная ошибка для UNIX-систем - это забыть установить параметр настройки ulimit в значение unlimited, однако есть и другие важные параметры, в том числе и для других платформ. Чтобы избежать этого типа проблем, необходимо изучить информацию в документах IBM Diagnostics Guide (руководства по диагностике) или на Web-сайте поддержки ПО IBM (в разделе Ресурсы приведены ссылки на оба эти источника), проведя поиск технических заметок для конкретных платформ по ключевому слову "truncated core".


Использование Dump Analyzer из IBM Support Assistant

Об IBM Support Assistant

IBM Support Assistant - это бесплатный сервисный инструментарий для решения проблем с ПО IBM. В ISA входит средство поиска, которое охватывает большие объемы документации от IBM и сортирует результаты для просмотра.

ISA также предоставляет функциональность для просмотра информации о продукте, включая ссылки на домашнюю страницу продукта и странице его службы поддержки, руководства по устранению неисправностей, различные форумы и группы новостей. Функциональность Service в ISA помогает собрать информацию о вашем компьютере и подготовить отчет о проблеме для IBM.

Набор инструментов ISA предоставляет диагностические инструменты для решения проблем, связанных с продуктами IBM. Эти инструменты постоянно обновляются и позволяют запускать на рабочем столе инструменты для диагностики и устранения проблем. В разделе Ресурсы приведена ссылка для загрузки ISA.

Основное средство для работы с DA - это IBM Support Assistant (далее ISA). ISA доступен для всех внутренних пользователей IBM и внешних клиентов (см. ссылку для загрузки в разделе Ресурсы).

Установить Dump Analyzer в ISA можно следующим образом:

  1. Убедитесь, что установлена версия ISA Version 3.
  2. Для установки DA необходимо установить плагин для продукта, который будет использоваться, например IBM Developer Kit for Java (соответствующие инструкции приведены в разделе Ресурсы.)
  3. Перезапустите клиент ISA. Теперь можно установить плагин для инструмента.
  4. Перейти к службе Updater (обновление). Для этого есть два способа:
    • Нажать на пиктограмму Updater на странице Welcome.
    • Нажать на ссылку Updater на панели меню.
  5. Выберите вкладку New Plug-ins (новые плагины) и подождите, пока ISA построит каталог плагинов, доступных для установки.
  6. Откройте узел Common Component Tools (стандартные компоненты-инструменты).
  7. Выберите IBM Dump Analyzer for Java (Tech Preview) и установите его.

После установки DA его можно запустить из ISA:

  1. Перезапустите ISA.
  2. Выберите меню Tools (инструменты)..
  3. Выберите продукт, для которого доступен DA, например, IBM Developer Kit for Java.
  4. Нажмите на пункт IBM Dump Analyzer for Java (Tech Preview) для запуска инструмента. Экран программы должен выглядеть так, как показано на рисунке 1:
Рисунок 1. Dump Analyzer внутри ISA
Рисунок 1. Dump Analyzer внутри ISA

Порядок действий для анализа отформатированного дампа системы:

  1. Введите полное имя файла с форматированным системным дампом для анализа.
  2. Нажмите кнопку Estimate Time (оценить время), чтобы получить грубую оценку времени, которое потребуется на выполнение анализа.
  3. Нажмите кнопку Analyze (анализировать). Результат будет показан в окне после завершения анализа.

На рисунке 2 показан пример отчета об ошибке, созданный DA:

Рисунок 2. Пример отчета об ошибке
Рисунок 2. Пример отчета об ошибке

Нажатие на кнопку Analyze Another возвращает к экрану, показанному на рисунке 1, на котором в первом текстовом поле по-прежнему находится ранее введенное название файла дампа.

Выбор модуля-анализатора

Поле Optional Parameters (дополнительные параметры) на экранах запуска на рисунках 1 и 2 определяет набор анализаторов, которые надо выполнить, а также другие параметры времени исполнения. Обычно это поле можно оставить пустым, в этом случае будет выполнен сценарий анализа по умолчанию - general.sml. Это сценарий проверяет дамп на предмет наиболее обычных типов проблем. Однако если уже известен конкретный тип проблемы, с которой необходимо работать, или требуется работать над проблемой, не входящей в сценарии по умолчанию, можно явно указать для запуска один или несколько анализаторов. Эти анализаторы могут быть вызваны по имени конкретного файла сценария или по имени класса конкретного модуля-анализатора. Введя -help в поле Optional Parameters, можно получить список дополнительных параметров, которые можно использовать во время исполнения.

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

  • DefaultDumpReport (класс: com.ibm.dtfj.analyzer.deal.basic.DefaultDumpReport): Этот анализатор готовит довольно подробный отчет по всем основным аспектам состояния VM, похожий на то, что можно найти в файле Javacore (но с некоторой дополнительной специфической для DTFJ информацией).

  • ListZipJars (класс: com.ibm.dtfj.analyzer.deal.extended.ListZipJars): Этот экспериментальный анализатор пытается найти все zip- и JAR-файлы, открытые в VM в данный момент, что может помочь определить, какие специальные библиотеки используются приложением или промежуточным ПО.

  • SystemProperties (класс: com.ibm.dtfj.analyzer.deal.extended.SystemProperties): Этот экспериментальный анализатор сканирует VM и печатает текущее значение всех системных Java-свойств, определенных в этой машине.

  • WASBasicInfo (класс: com.ibm.dtfj.analyzer.deal.was.WASBasicInfo): Это предварительная экспериментальная версия анализатора, демонстрирующая использование этого инструмента для исследования состояния сервера приложений WebSphere Application Server во время его работы внутри VM.

Эти анализаторы представлены для того, чтобы продемонстрировать гибкость инструмента. Будущие версии будут включать множество дополнительных специализированных анализаторов с соответствующей документацией. Также в четвертой статье этой серии будет показано, как писать собственные анализаторы в дополнение к поставляемым с инструментом.


Использование DA из командной строки

В некоторых ситуациях может оказаться удобным запускать DA из командной строки, например, если анализ нужно встроить в уже существующий процесс обработки проблем. Проще всего использовать DA через ISA, как было показано выше.

Чтобы запустить DA в автономном режиме, потребуются четыре JAR-файла и файл сценария:

  • dumpAnalyzer.jar (находится в каталоге каталог_установки/plugins/com.ibm.java.diagnostics.dbda.isa_(номер версии)/WEB-INF/lib)
  • dtfj-interface.jar (находится в каталоге каталог_установки/plugins/com.ibm.java.diagnostics.dbda.isa_(номер версии)/WEB-INF/lib/j9)
  • dtfj.jar для Java 5.0 и более свежих версий (находится в каталоге каталог_установки/plugins/com.ibm.java.diagnostics.dbda.isa_(номер версии)/WEB-INF/lib/j9)
  • dtfj.jar для Java 1.4.2 (находится в каталоге каталог_установки/plugins/com.ibm.java.diagnostics.dbda.isa_(номер версии)/WEB-INF/lib/sov)
  • general.sml (находится в каталоге каталог_установки/plugins/com.ibm.java.diagnostics.dbda.isa_(номер версии))

Во всех этих путях каталог_установки означает каталог, где установлен ISA; по умолчанию это C:\Program Files\IBM\IBM Support Assistant v3 в Microsoft Windows или /opt/IBM/IBM Support Assistant v3 в Linux®. Эти файлы можно скопировать в любой удобный каталог или запустить DA прямо из каталога каталог_установки/plugins/com.ibm.java.diagnostics.dbda.isa_(номер версии). Хотя инструмент ISA доступен только для Windows и Linux, запустить DA из командной строки можно на любой платформе.

Команды для запуска DA из командной строки в каталоге по умолчанию на ОС Windows:

  1. set CP=WEB-INF/lib/dumpAnalyzer.jar
  2. set BCP=WEB-INF/lib/j9/dtfj.jar;WEB-INF/lib/j9/dtfj-interface.jar;WEB-INF/lib/sov/dtfj.jar
  3. java -cp %CP% -Xbootclasspath/p:%BCP% com.ibm.dtfj.analyzer.base.DumpAnalyzer (dumpName) (options)

Порядок действий для Linux:

  1. export CP=WEB-INF/lib/dumpAnalyzer.jar
  2. export BCP=WEB-INF/lib/j9/dtfj.jar:WEB-INF/lib/j9/dtfj-interface.jar:WEB-INF/lib/sov/dtfj.jar
  3. java -cp $CP -Xbootclasspath/p:$BCP com.ibm.dtfj.analyzer.base.DumpAnalyzer (dumpName) (options)

Параметр dumpName - это полное название дампа, который нужно проанализировать, а options - параметры для настройки работы, которые можно использовать для конфигурации DA. Запуск с параметром -help выводит список доступных параметров.

На рисунке 3 показан снимок с экрана, содержащего фрагмент информации, выводимой DA при запуске из командной строки:

Рисунок 3. Пример информации, выводимой DA при запуске из командной строки
Рисунок 3. Пример информации, выводимой DA при запуске из командной строки

Дополнительную информацию о DTFJ можно найти в разделе Ресурсы.

Планы на будущее

На момент написания статьи была доступна начальная версия инструмента DA. Наша команда планирует продолжать регулярно вносить в него усовершенствования и обновления. В особенности мы фокусируемся в двух областях:

DTFJ: архитектура, лежащая в основе Dump Analyzer

Для исследования форматированных системных дампов инструментарий DA использует технологию DTFJ. DTFJ - это API, поддерживающий разработку диагностических Java-инструментов, которые могут анализировать системный дамп, взятый из VM. Чтобы дамп системы можно было исследовать, его необходимо сначала обработать утилитой jextract для добавления информации, относящейся к среде исполнения Java. Важно, чтобы обработка дампа системы утилитой jextract (в командной строке нужно набрать: jextract core.dmp) выполнялась с использованием той же версии Java-платформы и на том же компьютере, где был получен дамп системы. После того как это сделано, получившийся файл (.sdff для версии 1.4 Java-платформы или .dmp.zip для версии 5.0 и выше) может быть исследован на любой системе.

Первый этап анализа с помощью DTFJ - это построение DTFJ-образа с использованием соответствующей фабрики образов. Эта фабрика зависит от уровня используемой VM и обладает внутренним представлением о формате дампа для конкретной платформы. Полученный образ представляет полный образ операционной системы, он предоставляет методы для доступа к информации об архитектуре компьютера, на котором был получен дамп системы, но главная его функциональность - это обеспечить возможность исследования адресных пространств, содержащихся внутри образа. С помощью API-интерфейса DTFJ можно переходить от образа к подробным параметрам среды исполнения, Java-потокам, платформенной среде и объектам в куче. Этот интерфейс позволяет инструментальным средствам осуществлять анализ проблем и создание отчетов с информацией.

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

Особенно интересна область разработки новых анализаторов. Технология DTFJ для анализа дампов предоставляет удобный механизм для исследования низкоуровневых элементов VM, таких как потоки и объекты-мониторы, для диагностики ошибок переполнения памяти, сбоев, блокировок и т.д. Кроме того, можно анализировать содержимое любой структуры данных, находящейся в VM. В частности, можно анализировать содержимое различных структур данных, являющихся частью реализации приложения или промежуточного ПО, работающего внутри VM. Мы планируем начать разработку набора анализаторов, которые будут использовать эту информацию для диагностики различных проблем с сервером приложений WebSphere Application Server и, возможно, других продуктов стека ПО.

Наша цель - сделать этот инструмент как можно более полезным, так что мы будем очень рады откликам - как о самом инструменте, так и о тех анализаторах, которые вы хотели бы в нем видеть. Комментарии можно направлять через ссылки в этой статье или через ISA.

Далее в этой серии

Следующая статья этой серии знакомит с инструментом Garbage Collection and Memory Visualizer (визуализатор сбора мусора и памяти). Этот инструментарий может быть полезен для исследования связанных с памятью проблем с производительностью Java за счет анализа подробных журналов выполнения сборки мусора. С помощью этого инструмента можно анализировать характер использования памяти, определять наличие утечек и настраивать конфигурацию сборщика мусора для повышения производительности.

Мы вернемся к Dump Analyzer в четвертой статье этой серии. В ней будет представлен более подробный отчет о расширяемости этого инструмента и показано, как строить для него собственные аналитические модули.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=340071
ArticleTitle=Диагностика Java в стиле IBM: Часть 1. Знакомство со средствами диагностики и мониторинга IBM для Java: Dump Analyzer
publish-date=09192008