Too many policy logs!

alexjdale
Valued Contributor III

I have a problem where the JSS has too many logs saved (I think the default setting was one year), to the point where the JSS/Tomcat hang when I try to view logs for some policies (like the daily inventory policy) and stop accepting incoming connections. I usually have to reboot the server to restore service.

What's the best practice for keeping policy logs from backing up to the point where this occurs? How do I safely clear them out if the JSS can't even process them? I'm worried if I change the retention date to 90 days, it will kill the JSS/MySQL.

1 ACCEPTED SOLUTION

keaton
Contributor
Contributor

Hey @alexjdale][/url][/url,

I would trim down the logs what best suits your environment. If we don't need to go back a year, for large environments we recommend to set it down to at least 3 months.

If the logs haven't been flushed in awhile, we suggest manually flushing each section one at a time down to your desired time. This should help keep the JSS from crashing.

For example:
Application Usage Logs >> Flush Logs Older Than: One year >> Flush
Application Usage Logs >> Flush Logs Older Than: Six Months >> Flush
Application Usage Logs >> Flush Logs Older Than: Three Months >> Flush

Computer Usage Logs >> Flush Logs Older Than: One year >> Flush
Computer Usage Logs >> Flush Logs Older Than: Six Months >> Flush
Computer Usage Logs >> Flush Logs Older Than: Three Months >> Flush

So on and so forth..

Let us know if you have any other questions!

Thanks,
Keaton

View solution in original post

3 REPLIES 3

keaton
Contributor
Contributor

Hey @alexjdale][/url][/url,

I would trim down the logs what best suits your environment. If we don't need to go back a year, for large environments we recommend to set it down to at least 3 months.

If the logs haven't been flushed in awhile, we suggest manually flushing each section one at a time down to your desired time. This should help keep the JSS from crashing.

For example:
Application Usage Logs >> Flush Logs Older Than: One year >> Flush
Application Usage Logs >> Flush Logs Older Than: Six Months >> Flush
Application Usage Logs >> Flush Logs Older Than: Three Months >> Flush

Computer Usage Logs >> Flush Logs Older Than: One year >> Flush
Computer Usage Logs >> Flush Logs Older Than: Six Months >> Flush
Computer Usage Logs >> Flush Logs Older Than: Three Months >> Flush

So on and so forth..

Let us know if you have any other questions!

Thanks,
Keaton

chris_kemp
Contributor III

I had issues (with upgrades) when I was keeping way too many logs. Our database was over 20GB because of this. I screwed the level WAY down, to a few weeks (or months for usage statistics) and it slimmed it down to just a couple of GB. As I understand it, those daily recon reports pile up, when you could easily just keep the most current one - it doesn't delete the last record, even if it's outside of the date scope (i.e. older than 90 days, or whatever).

I seriously doubt you'll kill the system by dialing it back to 90 days - in fact, I would expect it to improve.

alexjdale
Valued Contributor III

Thanks for the input, folks! I have maintenance scheduled for next week (upgrading 9.22 to 9.24) and I will dial back the retention dates and do a stepped flush to bring things in line.