Влияние логов на производительность системы

Тут может быть дело не в размере логов.

По поводу логов, тут вариантов масса, а принципе любой актуальный и не совсем умеют в ротацию логов, нужно больше данных о приложении: какой логгер используется? В корне приложения есть log4j.* или logback.* файлы?

Иногда причину падения можно увидеть в логах.

Может ли быть какой-то предел роста логов?

Немного о логах посмотри здесь.

+1, с чего ты вообще построил какую-то связь логов с падениями? Аргумент уровня «я старею — приложение падает» очевидно не защитывается.

1) Логгер импользуется-logrotate.
2) log4j* и logback.* обнаружены не были.
3) Ротация логов еженедельная, как я понял, со сжатием.

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

У меня ещё такая проблема, что совсем не знаком с Java и не знаю за что браться при анализе падений, допускаю, что этим должен заниматься программист =) Понимаю, что первым делом наверное нужно изучать логи.
Нет среди присутствующих, практикующих администрирование java приложений, может есть какой 101 курс для полных нубов?

+2 но убедить автора похоже не удасться

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

Господа, хочу внести немного ясности:

Я не утверждаю, что причина падений в размере лог-файлов и уже понял, что вероятно это в принципе не может быть причиной
Приложение клиент-серверное, есть несколько клиентских интерфейсов на которые передаются и с которых принимаются данные-это и сайт и андроид приложение
Помимо основного приложения есть ещё ряд сервисов типа firebase и email-sender
Почему-то пишется только catalina.out и localhost.log, а catalina.log и manager.log не пишутся совсем
Я бы мог использовать отладку, но совсем не знаю java и внутреннее устройство приложения, этим занимается отдельный человек, который вместе с этим совсем не знаком с linux, администрированием и настройкой того же tomcat

А в логах есть хоть варнинги? Если есть только информационные сообщения, то стоит покопаться в документации к классам как можно повысить уровень логгирования с помощью командлайн параметров.

Смотри размер лога, подозреваю падает при 2 Гб или 4 Гб размере.

Логи видимо самописные. Если так - настрой logrotate для них

Варнинги есть:
WARNING [https-jsse-nio-48443-exec-5] org.apache.cxf.phase.PhaseInterceptorChain.doDefaultLogging Interceptor for {http://service.ws.bc/}MobileClientServiceService#{http://service.ws.bc/}getUserInfo has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: java.net.SocketTimeoutException

То есть большой размер лога может играть роль?
Спасибо за совет, как раз разбираюсь с logrotate

гуглить по каким-то ключевым словам

org.apache.cxf.interceptor.Fault

А какое потребление памяти? Может oomkiller приезжает?

А ты кто есть в пищевой цепочке? Разраб, тестировщик, девопс, внедренец, админ?

Как я понял, ранее имело место падение из-за высокого потребления памяти, но сейчас в кроне каждый час чистятся inode, dentrie и PageCache и памяти хватает.
Выглядит, конечно как костыль, но как это решить на уровне tomcat не знаю, в топе потребления оперативы, к слову процессы базы данных, хз что с этим делать.
Внятных гайдов как из терминала управляться с oracle db не нашёл.

Что-то между админом и девопсом, по факту было так: «Ты вроде знаешь пару команд в линухе, помоги пожалуйста, тут что-то не работает» =)
Но мне уже самому интересно разобраться, на будущее

А в логах ОС oomkiller приезжает или нет?

В /var/log/messages упоминаний oom не было.
И помимо lastlog, secure и cron других системных логов нет

процессы базы данных, хз что с этим делать.

Ничего не делать, это кэш БД, для того, чтобы не дергать диски.

БД лучше знает, что ей кэшировать и кэширование обычно идет в обход дискового кэша