email builder wrote: [snip] > Respectfully (you sound like you know a hell of a lot more than I do about > these things), the OP presumably (hopefully?) does more than look once at top > and send out emergency emails to this list. I personally watch system load > (just from "w" command as well as top) several times a day as well as watch > my overall mail queue sizes. And I think I can be pretty sure that the CPU > usage spikes from clam are not flukes -- while "top" may not be as useful as > prstat (which I am not familiar with but will research, thank you (anyone > have a favorite link for prstat?)), it *is* still surely of some use, > especially when watched regularly and in combination with seeing higher > average queue backups than when using clam .80
prstat is a Solaris command, it doesn't exist anywere else AFAIK, my recomendation could be seen with top itself: many times top is one of the processes that uses most of the CPU. Now the point of my remark has to do with statistics. A few data points don't lead to meaningful statistics; what you can do with top is limited, nevertheless if you or anybody sees high CPU usage that is interesting even if it doesn't tell you why, i.e. it could be high message load, it could be attachments in messages, it could be a combination of those or something else. >>>Anyone have any suggestions with .80 or .84 CPU load issue. >> >>Tune up clamd. That means adjusting the MaxConnectionQueueLength, >>MaxThreads, >>ArchiveMaxFileSize, ArchiveLimitMemoryUsage options on clamd.conf taking >>into >>consideration that RAM is limited. > > > I hear that. Our situation is such that we see no swapping, but still lots > of CPU consumption. But I am willing to be educated on better clam settings, > since we haven't tweaked extensively in that regard.... but still, .80 with > the same config was pretty quiet on our system. The OP has stated that RAM is not the problem. I'm just trying to guess the environment and that was a bad assumption. Now wrt 0.80 vs 0.85, my point about the benchmark is that if you don't compare them under similar conditions the comparison is invalid. Think about this, did 0.80 catch as many viri as 0.85 when you messured? As for tunning, the main parameters are the number of threads and what to skip (I usually don't want really big messages scanned, viri come in around 50KB no need to check 2MB or more; but this is from experience and recomendations, so it's really only an heuristic). Regards. -- René Berber _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
