опыт отладки высоконагруженных java-приложений

Собираешься наегорить будущего работодателя? Всплывёт же.

Макса спроси с хизелем ☺

Собираешься наегорить будущего работодателя? Всплывёт же.

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

Что имеется в виду?

Упоминание этого баззворда в объявлении повышает ЧСВ работодателя.

что такого особенного есть в этой отладке (по сравнению с отладкой низконагруженных приложений)

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

что примерно будут спрашивать на собеседовании

Конкретно про яву - ХЗ. Обычно ожидают понимания, что оптимизировать надо не все что угодно, а критичные цепи. А под опытом наверное подразумевают, что вы эти критичные цепи будете быстро искать.

Выбудете смеяться, но очень многие «разработчики» действительно не понимают, что бывают блокировки, гонки, нагрузка на CPU и т.п.

См. инструменты JMeter и VisualVM.

1. Хорошо знать используемую в проекте RDBMS (например для MySQL надо знать как работают и что делают индексы, знать как использовать EXPLAIN и т.п.), memcached, Redis.

Говори, что твой мегаопыт показывает, что самый нормальный вариант отладки высоконагруженных java-приложений в продакшене это логирование - тоесть пихание логов и составление по ним карты действий с таймингами.
Дальше уже ваш мозг с плюсами и минусами этого решения. :-)
«Если бы у динозавра была шерсть, то в неё водились бы блохи. » - ключевое правило на собеседовании, если не знаешь чего вещать.

В первую очередь это отладочный вывод vm (gc статистика и так далее). Потом это visualvm, там смотри visual gc, CPU sampler. Почитай про jps, jstat, jstack. Логирование - само собой.

ну можно уметь отвечать в чем отличия между профилированием и семплированием 8)

ну и сама идея отладки, а то перефразируя шутку с башорга:

anonymous> Насчет файеров: я так понимаю с ними напрочь в Linux туго.
ovax> Для господ вин-админов фаервол - это окошечко, которое выскакивает на 
      экране с надписью "программа svchost.exe пытается обратиться по адресу 212.122.1.2:53"
      и надо кликнуть мышкой "разрешить / запретить" ???
ovax> Тогда да. туговато. Провайдеры обычно не успевают кликой мышкой на магистральном канале. :-)

как вы будете брекпоинты ставить?

Брейкпоинты нужно ставить условные. В качестве условия удобно брать что-то вроде идентификатора транзакции.

гм, гм, если у нас приложение не энтерпрайзное то там транзакций может и не быть

Я имел в виду более общее понятие транзакции. «Номер операции». Как конкретный вариант такое из практики: на nginx-е проставляется заголовок x-request-id, далее этот заголовок таскается внутри системы с помощью org.slf4j.MDC и во-первых логируется, во-вторых используется для дебаг, для этого есть возможность этот заголовок передать самому.

самое важное в высоконагруженных приложениях - чтобы все было просто и тупо. Джойнов поменьше, где без них нельзя - nosql. Скрипты попроще, чтобы работали линейно. Памяти чтобы известно, сколько жрется. Логи в партицированные таблицы. Самая первая «отладка» - отладка архитектуры. Если просрал архитектуру, то вывезти ситуацию микроменеджментом сможет только настоящий гений. А если все просто и тупо - то и отладка простая и тупая, это тебе не хацкель сношать. Кстати, никакого хацкеля) Там, дедлоки пофиксать. Базу данных починить без рестарта сервера. Вообще все без рестарта сервера, а если с рестартом - как правильно это делать.

гм, гм, если у нас приложение не энтерпрайзное то там транзакций может и не быть

разверни мысль? Зачем специально отключать транзакции в «неэнтерпрайзном» приложении?

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

Отказ от ACID это вообще классика хайлоада. Амазон тот же или lmax, положили болт на транзакции.

ну не путай отказ от ACID и отказ от транзакций

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

То есть можно отказаться от транзакций, но не отказаться от acid? А можно по-подробней? Я думал что это теже яйца.

не ну сама идея ACID предполагает наличие транзакций, но с точки зрения сохранения консистентности данных и некоторых других вещей можно выкрутиться

например так http://habrahabr.ru/post/153321/

там куча хрени но обрати внимание на три буквы CAS - это какбы основа многих неблокирующих алгоритмов.

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

Я про отказ имел в виду как в lmax - там реально все на одном хосте и без транакций и без acid. Типа хорошее железо юзают и хорошо трестируют код + ведут журнал операций для DR.

это те же транзакции, только реализованные самостоятельно

неа, эти транзакции по сути «на одну запись» (документ в mongo), а не гигабайт всякой хрени из двух десятков таблиц

Ну какая разница? Двухфазная транзакция. В постгре есть встроенные, примерно так и работают (row level lock). Все это вопрос реализации, транзакции никуда не делись.

бгг если ты не отличаешь транзакции от CAS то тут не о чем вообще разговаривать

Я тебе про то, что получается вместе, а не что внутри, это обычная двухфазная транзакция, реализованная на нескольких cas-ах. А то что внутри, я же написал «примерно». Лок строки и cas это примерно один порядок производительности, никакой херни на гигабайт там нет.

Я тебе про то, что получается вместе, а не что внутри

Это шизофения, определенно. Ты путаешь болт и машину.

Внутри то что ты накрутишь - пойми это.

Лок строки и cas это примерно один порядок производительности, никакой херни на гигабайт там нет.

Бред сивой кобылы, лок и cas - это даже с большого бодуна не одно и тоже, тем более с высоким уровнем изоляции это потребует копирования.

лок и cas - это даже с большого бодуна не одно и тоже
Он и не говорил, что это одно и то же.