Solved

logrotate ... uses excess cpu    ?

Posted on 2012-03-28
6
591 Views
Last Modified: 2012-04-06
we are getting a huge server load every day and we found it to be logrotate that stops server

in logs we find

  Mar 28 06:58:56 u15331601 statistics: Unable to get current data: Table 'psa.SitePagesStat' doesn't exist
Mar 28 06:58:56 u15331601 statistics: Unable to clear data: Table 'psa.SitePagesStat' doesn't exist
Mar 28 06:59:05 u15331601 statistics: Unable to get current data: Table 'psa.MailMessagesStat' doesn't exist
Mar 28 06:59:05 u15331601 statistics: Unable to clear data: Table 'psa.MailMessagesStat' doesn't exist




problem  is we do not have these tables

can we create empty tables to solve problem  or??
0
Comment
Question by:webguy62
  • 3
  • 2
6 Comments
 
LVL 24

Expert Comment

by:johanntagle
Comment Utility
I doubt if the missing tables are the ones causing high load.  How did you determine it was logrotate consuming the cpu?  Did you use a utility like top?
0
 
LVL 34

Expert Comment

by:Duncan Roe
Comment Utility
You have an application that is logging these messages. That will severely impact the system, unless you put a minus ("-") sign in front of that log file name in /etc/syslog.conf . The effect of not having a minus sign is that the entire file system is sync'd every time a message is logged (i.e. all written buffers are flushed to disc before proceeding).
In the long run, you want to find what application is logging the messages. You may decide it is not of sufficient value to be running at all. Otherwise, its documentation should point you to the real meaning of the messages, and what you have to do to stop them being logged.
0
 

Author Comment

by:webguy62
Comment Utility
yes we ran top and saw it was logrotate

now we have to killall - 9 logrotate

how do we find what causes the logrotate to use all cpu?
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:webguy62
Comment Utility
the below is syslog.conf    do we need to change this? I was told one of our guys manually deleted some logs in a few domains that were real large. could this cause it? and if so how to fix

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                          /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none            /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                    /var/log/secure

# Log all the mail messages in one place.
mail.*                                    -/usr/local/psa/var/log/maillog


# Log cron stuff
cron.*                                          /var/log/cron

# Everybody gets emergency messages
*.emerg                                          *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                    /var/log/spooler

# Save boot messages also to boot.log
local7.*                                    /var/log/boot.log
0
 
LVL 34

Accepted Solution

by:
Duncan Roe earned 500 total points
Comment Utility
In view of the number of messages you are getting, I would change /var/log/messages to -/var/log/messages (with minus sign as you already have for mail).
logrotate looping is highly unusual. If your guy had to delete some large files, it would seem that logrotate wasn't working anyway, or perhaps wasn't well configured.
To find out what logrotate is doing, first determine its process ID (pid). If the loop it is in includes a system call, strace will show something: strace -f -p pid.
Failing that, you are probably looking at building logrotate from source with debug symbols and attaching to the process with gdb. But lsof (list open files) may give you a clue: lsof -p pid.
Just possibly, logrotate has encountered some kind of file system corruption which has led it astray. Before going the gdb route, you might like to try a forced fsck (file system check) of the partition containing the log files. I'm assuming for now you know how to do that (single-user, remount root (/) read-only, ...)
0
 

Author Closing Comment

by:webguy62
Comment Utility
this solved the problem it took few days to monitor the server to verify but all is well now :)
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Hi, in this article I'm going to teach you how to run your own site, and how to let people in (without IP). I'll talk about and explain each step... :) By the way, everything in this Tutorial is completely free and legal. This article is for …
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now