Ротация файла журнала сборщика мусора (loggc) с помощью logrotate не работает должным образом

Question

Я столкнулся со странной проблемой при использовании опции журнала сбора мусора JVM с командой Linux logrotate. Когда вращение выполняется, оно заполняет значения NUL (^ @) первой строкой файла, заданной в качестве аргумента JVM.

Допустим, это Java-вызов (Test.class находится в / home / test /):

java -Xloggc: /home/test/test.log -cp / home / test / Test

Конфигурация logrotate для этого файла следующая:

/ home / test / test.log {
повернуть 56
пропавший
notifempty
copytruncate
не создавать
nomail
}

У меня также есть запись в crontab каждую минуту для тестирования:

* / 1 * * * * / usr / sbin / logrotate -f /etc/logrotate.d/gcLog

Я пришел к выводу, что JVM пишет в режиме добавления и сохраняет какое-то смещение, используемое для записи следующей строки в связанном файле, даже если файл урезан logrotate (я могу ошибаться).
< бр />

Моей следующей идеей было попытаться перенаправить стандартный вывод в файл test.log. Я использовал этот вызов Java и сохранил ту же конфигурацию для logrotate и cron:

java -verbose: gc -cp / home / test / Test> /home/test/test.log

Еще раз, когда test.log усекается logrotate, новый созданный файл заполняется значениями NUL (^ @) в первой строке.

Нет необходимости говорить, что я не нашел ничего полезного с помощью Google. Я обнаружил еще один вопрос, связанный со стековым потоком, но мне не удалось настроить Java Script Wrapper, поэтому он не работает.

Кто-нибудь сталкивался с этой проблемой? Есть идеи, почему это происходит? Лучше, обходной путь или решение? Мне нужно попытаться направить вызов приложения к какому-нибудь скрипту, читающему вывод, и, возможно, посмотреть, как Tomcat регистрирует и поворачивает стандартный вывод в catalina.out (здесь некоторая помощь также будет очень полезна)

Answer 1

У нас была та же проблема на нашем компьютере с Jboss7 и Java6, мы получали NULL в файле GC, и они просто продолжали расти.

Решением было просто войти GC в стандартный вывод, а затем добавить стандартный вывод в файл:

Простой пример:

java -verbose:gc >> console.log

Очевидно, использование append (>>) избавляет Java от «указателя» на позицию в файле. С дополнительным бонусом отсутствия сброса журналов GC при перезапуске сервера, поэтому мы можем получить некоторую статистику с течением времени.

По крайней мере, у инструмента IBM PMAT нет проблем с синтаксическим анализом sysout с выводом GC.

Самое простое решение - иногда самое лучшее :)

Хотелось бы, чтобы Java поддерживала ротацию логов GC, как я вижу, кто-то уже обсуждал: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-April/002061.html

Answer 2

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

Я виделнесанкционированное вмешательство в файлы журнала GC, вызывающее сбой системы, прерывание, вызванное тем, что он записывает в файл журнала, игнорируется (см. код здесь http://pastebin.com/HWkNv3PM), в результате чего JVM продолжает игнорировать ошибку.

Поскольку файл открывается снова, я считаю, что счетчик положения не сбрасывается.

Что касается других идей о том, как свернуть файлы журналов - см. Также: Прокручивание журналов сборщика мусора в java

Answer 3

Простой обходной путь может заключаться в изменении вызова Java, который я использовал в своем вопросе:

java -Xloggc: /home/test/test.log -cp / home / test / Test

до

java -verbose: gc -cp / home / test / Test |tee -a / home / test / test / log

Конфигурация logrotate и cron может остаться прежней (даже если период cron должен быть увеличен).

См. мой комментарий подвопрос по ссылке, дающей более подробную информацию о logrotate и обработчиках файлов в Linux.См. Также объяснения brainzzy о поведении Java.

Answer 4

вместо java -verbose: gc >> console.log я могу сделать: java -Xloggc: logs / gc.log >> console.log, чтобы выходные данные были сохранены в файле, а затем также преобразованы в console.log