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.

Actually you are, but they are immediately restarted.


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:

Code:

[srvbd1]root]/]>vmstat -v
[...]
                 20.0 minperm percentage
                 80.0 maxperm percentage
                 80.0 maxclient percentage
[...]

Code:

[srvbd1]root]/]>svmon -G
               size      inuse       free        pin    virtual
memory      2035712     982932    1052780     384894     702631
pg space    2097152       2404

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.

Code:

[srvbd1]root]/]>iostat 5

System configuration: lcpu=4 drives=3 paths=2 vdisks=0

tty:      tin         tout    avg-cpu: % user % sys % idle % iowait
          0.0         11.6                0.3   0.7   98.9      0.2

Disks:        % tm_act     Kbps      tps    Kb_read   Kb_wrtn
hdisk0           2.0       3.2       0.4          0        16
hdisk1           2.0       6.4       0.8          0        32
cd0              0.0       0.0       0.0          0         0

tty:      tin         tout    avg-cpu: % user % sys % idle % iowait
          0.0         77.6                0.3   1.5   97.9      0.3

Disks:        % tm_act     Kbps      tps    Kb_read   Kb_wrtn
hdisk0           0.2      11.0       2.4          0        56
hdisk1           0.2       7.9       1.2          0        40
cd0              0.0       0.0       0.0          0         0

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.

I hope this helps.

bakunin