Ситуация:
Есть некая ЕЕ система.
Кратко : сервлету приходит xml запрос - дальше дёргаем SessionBean, который логирует этот запрос в базу, вызывает другие бины - формируется ответ, - опять же ответ логирутся в базу.

Проблема: Иногда сервер логов "тупит" (система обрабатывает около 60000 запросов в час), и как результат тормозит вся система. Систему научили реагировать на падение сервера логов (логи отключаются) , осталось побороть дуплёж.

Вопрос:
1. У кого как организовано логирование ?
2. Как можно минимизировать зависимость системы от логирования ?
3. Как можно определить, что СУБД "тормозит" ?


ЗЫ: Купить новый сервер для логов, не предлагать - у организации пока нет денег.

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


Желательно логи писать в отдельном потоке, и как очередь событий на запись в БД начнет расти, значит тормозит.

Посмотри эту темку.

вынести отдельный аппликатион серверок логгирования
ему переправлять JMSом данные для логгирования
на нём обрабатывать данные(преобразовывать к виду, который будет уже соббсно в логах) и оттуда уже пихать в базу.
Причём в базу - как описано в темке, которую LSD, скинул.
Т.е. с препаред стэйтмент + батчами. Причём тут батчи могут быть здоровенными в данном случае

Такие мысли были - но это также может ударить по производительности:
1. вызов бина на удалённом серваке.
2. лишний раз гонять трафик по сети. (100мб пришло в запросе, эти 100 мб передали другому апп-серверу и эти 100 мб - он заинсертил в базу)

3. Вопрос по ходу : как то можно определить количество сообщений, находящихся в очереди ?
Добавлено @ 12:50

можно поподробнее, пожалуйста?
У нас просто "инсерты".

Можно апп сервер запустить там где база с логами. в минимальной конфигурации.
Мысль такая - всё равно обрабатывать надо перед вставкой - правильно?
JMS позволит отказаться от подвисания боевого сервера из-за дупления логгирования.

Ну и вставка батчами + препаред стэйтмент - это в любом случае ))

Или попробовать "очередение" в оракле устроить.
Там очереди, кажись, можно мерять. ну и дизаблить/энаблить вставку/вытягивание из очедеди при необходимости.

Какими попугаями JMS можно мерять - не знаю Хотя, наверняка. такое есть

Это сообщение отредактировал(а) chief39 - 2.3.2006, 12:54

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

Скорее всего действительно, только использование JMS может сделать ядро независящим от логирования, но :
1. Очередь сообщений в таком случае может быстро переполниться. Причём в этой самой очереди могут находиться логи объёмом до 100мб - десять таких - уже гиг ... хотя очереди ж на диске , да ?

2. Тоже самое если накапливать их в MDB. Тут ещё один вопрос - как их накапливать ? статефул MDB ещё не придумали - тобеж как я понимаю под каждый вызов я буду дёргать "новый" МессагеБин.
Если попробовать статич. полем - боюсь оутофмемори.

Насколько я понимаю - они в памяти. Но если машину припрёт - то будет на диске (ака СВОП). Как бы не наткнуться на ограничение памяти под JVM.


Дык... сообщение -> МDB -> Session Bean -> база
связка мессэдж-дривен и сессион пусть работает как одно целое. Просто "пролёт" между боевым серваком и этой связкой станет асинхронным. То есть дупление сессион бина при вставке в базу не будет влиять на боевой сервак.

А может просто по-меньше логов писать, а?

ну ка посчитаем
60000 запросов умножаем на .. пусть будет в среднем 1 мегабайт, 100 мегов - немножко пугающая цифра,
итого получаем - 60000Х1000000=60Гигобайт в час. Не слабо, при такой нагрузке любая JMS ляжет.

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

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

ну не все запросы по 100мб - это получение списков, в основном поменьше ...
К сожалению с AspectJ не сталкивался - и с какой стороны подойти пока не знаю - буду благодарен за "волшебный пендель" в нужном направлении

Такую кляузу подготовил начальству :

Для уменьшения зависимости ядра АБС от подсистемы логирования были рассмотрены следующие возможные
пути решения:

1. Логирование в асинхронном режиме (MDBean)
Недостатки:
- необходимость поддержки ещё одного сервера с высокой нагрузкой;
- вызов бина на удалённом сервере (может повлиять на призвордительность);
- увеличение сетевого трафика;
- отсутствие гарантированного ведения логов;
- очередь сообщений в таком случае может быстро переполниться;
-

2. Определение лимита по времени на осуществление операци логирования, с последующим выключением логов.
Недостатки:
- потеря логов;
- сложность определения временного интервала (размер запросов варируется от 100кбт до 100мбт);
- если время на insert/update лога велико - не решит проблему (сервер "залипнет")
-

3. С целью уменьшения нагрузки на лог-сервер опционально не логировать запросы на list (только ins,mod,del)
Недостатки:
- не полное логирование;
- не является решением прпоблемы в полной мере;

4. Апгрейд лог-сервера;

5. Использование Log4j. (с подачи LSD)
Разработать свой Appender, который принимает сообщения и кладет в очередь, а фоновый процесс берет из этой очереди сообщения и пишет их в базу. Для очереди есть максимальная длинна, при превышении которой сообщения либо откидываются (наиболее новые, наиболее старые или по иному критерию, как будет удобно), либо логирование переводим на альтернативу (файл, сокет, почта)

как видно склоняюсь больше в сторону 4 и 5 пунктов. Если с 4 всё прозрачно, то с 5 надыть ещё покопаться. Если кто сразу увидит грабли - не дайте мне наступить

по поводу п.5 - адаптер для log4j работающий с очередями уже давно существует - JMS Appender, примеры работы с ним есть в дистрибутиве log4j-я, если я не ошибаюсь. Но опять же - он не решает проблему при таких нагрузках, и к тому же должна быть сама очередь, IBM MQSeries, MSMQ или что-то еще. Ведь для того что бы положить/взять из очереди требуются ресурсы, ведь очередь вещь не простая - как правило она включает в себя поддержку транзакций, а это дополнительные накладные расходы.

Как мне кажется, для вашего варианта решения чем проще - тем лучше, без всяких "рюшечек" в виде jms-а.

Гуд лак.

Да.
Но 5 пункт - это не JMS. Это JDBCAppender + AsyncAppender. (просто инсерты будут идти отдельным потоком...)

Это сообщение отредактировал(а) kostenko - 16.3.2006, 17:25