I see no "performance issue", just a "ps"-output. To assess the performance situation of your system it would be necessary to the output of:

Code:

vmstat -v
vmstat -tw 1
svmon -G
iostat 5
no -a

and, depending on the configuration of your system ("lscfg") probably some other.

Anyways, to kill the processes is easy. You see the columns labeled PID in your output:

Code:

kill -15 <pid>

then wait a few seconds, issue another "ps". If <pid> isn't gone:

Code:

kill -9 <pid>

I still have serious doubts that this will help your situation any and i fear it might make you situation even worse, but there you go. My recommendation is not to do it, but you are free to do as you please.

Thanks for your reply. Let me explain the issue with me right now. The server is completely empty, but still any application i start like WAS 'or' enterprise application is very slow like takes hours together. Even putty login takes like few minutes to login. So we analyzed and found only this wait process looked like bottlenect. But i m not sure, this being kernel process, i m not able to kill them.

Here i post the required details, please do review and let me know if you can find any reason for the server behaviour.

These are kernel wait processes. They are absolute normal and come with the OS, 1 per Logical CPU. As one can see you have 2 procs and I assume you have SMT activated with 2 Logical CPUs per virtual or physical CPU.

Thanks for your reply. Let me explain the issue with me right now. The server is completely empty, but still any application i start like WAS 'or' enterprise application is very slow like takes hours together. Even putty login takes like few minutes to login.

OK, this might as well be a problem with the server as it might be a problem with some third-party system. A possible cause could be the name server (have a look at /etc/resolv.conf), maybe the server runs into a timeout every time it tries to query an IP address. Try the following: select a server in your network. Make sure its IP address is not in the local /etc/hosts. Do a "ping <IP-address>" and note the time it takes to respond. Now try a "ping <hostname>" for the same server. If there is a noticeable difference in how long it takes "ping" to start the name server is the culprit.

Quote:

But i m not sure, this being kernel process, i m not able to kill them.

Actually you are, but they are immediately restarted.

Quote:

Here i post the required details, please do review and let me know if you can find any reason for the server behaviour.

OK, i had a quick look at your output and IMHO the system was doing absolutely nothing when you took the snapshots, it probably rebooted just before. If you look at "vmstat"s output and notice the lots of "free" memory pages there are only two possible reasons: either the system does absolutely nothing so that the kernel doesn't even know what to put into file cache - this is unlikely given your modest memory size of ~8GB. The other option is that the system just restarted and there was not enough I/O to this moment to fill the filecache with anything that makes sense. (The last possible explanation - a rather hilarious "maxperm"- "minperm"-, etc. setting - is ruled out by the output of "vmstat -v".)

You might want to tune your maxperm- and minperm-settings to more sensible values. What these values might be depends on the application, but 95% and 3% are good starting points. Right now you have:

This display is in memory pages (=4k). 2 Mio pages ~ 8GB. From these 2 mio pages 700k have been used, the rest is simply doing nothing. If this is everything your system ever does you could reduce its memory to ~4GB and everything would be fine.

These disks are doing absolutely nothing. The little activity residue is the system itself idling away. It is the computer equivalent of one twiddling his thumbs.

Code:

[srvbd1]root]/]>no -a

Looks like everything is at defaults here. Once the system will actually do anything there might be a reason to optimize a bit, but now just leave it alone.

I wonder what you want with the many adapters - you have no disks (save for the two system disks) right now.

Summary:

It seems that the system is built right now and some of the hardware ins't even connected (like disks). The system is definitely not the problem when a "putty" eds "several minutes" to connect. I'd look at the network (routers, firewalls, VLANs, etc.) and network-related services (DNS, NIS, maybe kerberos or LDAP, etc.) if the culprit is there. My first guess would be the name server, then the other components i named.

As exclaimed, yes the system was doing nothing at that point in time, they were completely idle. I was either trying to login to sqlplus from other session and it was taking 2 minutes for that 'or' may be some other things very general like bring up a small service.