Файл настроек производительности для log4j?

Вот мой текущий файл настроек log4j. Являются ли эти настройки идеальными для использования в производстве или есть что-то, что я должен удалить/изменить или изменить? Я спрашиваю, потому что я получаю все мои потоки, зависающие из-за блокировки log4j. Я проверил мои дескрипторы открытых файлов, в которых я использовал только 113.

# ***** Set root logger level to WARN and its two appenders to stdout and R.
log4j.rootLogger=warn, stdout, R

# ***** stdout is set to be a ConsoleAppender.
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
# ***** stdout uses PatternLayout.
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
# ***** Pattern to output the caller file name and line number.
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

# ***** R is set to be a RollingFileAppender.
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=logs/myapp.log
# ***** Max file size is set to 100KB
log4j.appender.R.MaxFileSize=102400KB
# ***** Keep one backup file
log4j.appender.R.MaxBackupIndex=5
# ***** R uses PatternLayout.
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %d %c - %m%n


#set httpclient debug levels
log4j.logger.org.apache.component=ERROR,stdout 
log4j.logger.httpclient.wire=ERROR,stdout 
log4j.logger.org.apache.commons.httpclient=ERROR,stdout 
log4j.logger.org.apache.http.client.protocol=ERROR,stdout

UPDATE *** Добавление образца дампа потока из всех моих потоков (100)

"pool-1-thread-5" - Thread [email protected]
   java.lang.Thread.State: BLOCKED on [email protected] owned by: pool-1-thread-35
    at org.apache.log4j.Category.callAppenders(Category.java:201)
    at org.apache.log4j.Category.forcedLog(Category.java:388)
    at org.apache.log4j.Category.error(Category.java:302)

Ответ 1

Log4j 1.2 уязвим для тупиков, когда toString() создает вложенную регистрацию.

См. старые стареющие все еще нерешенные проблемы, такие как Log4J может создавать условия взаимоблокировки (одновременное пожертвование пакетов) и Тупик с RollingFileAppender.

Он также имеет проблемы синхронизации блокировки производительности при большой одновременной нагрузке. Как Категория callAppenders синхронизация вызывает java.lang.Thread.State: BLOCKED и Переместите org.apache.log4j.Category для повторных попыток чтения/записи.

Даже AsyncAppender не содержит избыточных блокировок: AsyncAppender.doAppend() не нужно синхронизировать и Тупик в 1.2.15, вызванные классами AsyncAppender и ThrowableInformation. Также остерегайтесь Переполнение AsyncAppender.

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

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

Вложенные категории интересов могут быть индивидуально заданы при необходимости более низкими приоритетами.

Ответ 2

Создаете ли вы Logger для каждого класса, используя стандартный private static final Logger logger = Logger.getLogger(Foo.class);, где Foo - это класс, в котором объявлен логгер? Если у вас есть только один экземпляр Logger во всем приложении, может возникнуть конфликт, если есть много протоколов.

Ответ 3

% F:% L оказывает серьезное влияние на производительность. Хотя я не вижу, как они могут вызвать блокировку, я бы предпочел исключить их для производства.

Ответ 4

У этого парня, похоже, была аналогичная проблема (ссылка).
Это вызывает удивление, почему ваше приложение висит. Все ли они заблокированы в классах log4j? Я вижу, что, по крайней мере, вы опубликовали журнал "ERROR". Это может быть причиной?

Может быть, вы хотите опубликовать полный дамп?

Ответ 5

Это выглядит нормально. Я не вижу, как это может привести к блокировке log4j. Может быть, вы могли бы опубликовать ниспадающий поток вашей проблемы?