logrotate ... uses excess cpu ?

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??
webguy62Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

johanntagleCommented:
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
Duncan RoeSoftware DeveloperCommented:
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
webguy62Author Commented:
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
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

webguy62Author Commented:
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
Duncan RoeSoftware DeveloperCommented:
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
webguy62Author Commented:
this solved the problem it took few days to monitor the server to verify but all is well now :)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.