Tool that can determine source of smb processes that takes up much CPU time
 

Hi there --

We have Samba 3.0.0 (depot package) running on an HP-UX ServiceGuard 11.16 cluster. The cluster is comprised of two RP3440 RISC servers. There are three separate instances and configurations of Samba, one for each ServiceGuard package, that are running in the cluster. Two packages are on one server, while the third is on the other system.

We are periodically experiencing the smb process taking up a large amount of CPU time on the server that has two packages on it. I am trying to determine if a specific client system is the source of this problem. My thinking is when the client connects to the Samba mount, something on the client, i.e: web browser toolbar, might be causing the CPU usage to spike.

Is there a tool that can be used to determine the source of the CPU spike that is occurring on the server? Thanks.

I don't know how to monitor what is happening inside the samba processes except to increase the log level and then try to replicate the problem. Have you tried that yet?

I have not tried increasing the log level due to the simple fact that I don't know how that is done. Can you please elaborate? Thanks.

Sure - have a look in /etc/samba/smb.conf for the log level line and increase the number:
You probably shouldn't set it above 3 according to the info on the oreilly site. You'll need to restart Samba for the change to take effect.

I checked the smb.conf file, and it turns out the server generates a log file for every system that connects to the server.

Accordingly, my plan is to monitor the server closely, and when the high cpu usage occurs, I will go to the directory where the log files are located, and see which one(s) is/are the ones with most recent time stamp. One of those probably would be the origin of the problem.

What do you think?

That sounds good - you can leave a console window open with a tail running and watch as it happens:

I have an update concerning this issue. I pursued the strategy that we discussed, and when the spike occurred I compiled a list of the workstations that were connected to the Samba server at that time. I then did an on-site inspection of them, and there were five systems that had a web-browser toolbar. I removed the offending software, and the spike was no longer occurring on the server.

I am sure there will be other spikes that will occur, but I believe this course of action has helped for the time being, and will be one approach that will be used in the future.