telnet issues?

[Michael Elleby III_1]

Got one for you guys..

I have two L2000's that are similar in sw/hw configuration.

On each box, I have over 100 telnet sessions running to support RF Guns that are used in the same application running on both these servers.

The users on one of the boxes are complaining about response time, though I can find no culprit on the server or network that could be causing the response issue... I've also checked kernel params (npty, nstrpty and nstrtels) to no avail..

Any suggestions?

Thanx.

Mike-

[Sridhar Bhaskarla]

Hi Mike,

Check the hostname resolution on the box. Does it have resolv.conf, nsswitch.conf and hosts setup exactly like systemA?.

-Sri

[Jeff Schussele]

I agree with Sri.
Quite possibly lookup related.
Have the users do nslookups both by name & by IP & note response times. THEY may have a flaky resolver that's causing lookup delays.

Rgds,
Jeff

[monasingh_1]

I would start with their lan card half/full duplex setting.

Check any cron job which may be hampering the system.

Check if any of the disk mirror is giving away, but that should appear in syslog which I am sure you must have checked.See any unusual log in syslog.

check inittab file for any daemon which may be a culprit.

Compare the swap utilization on the sever, they shuld not be significantly different since both servers are identical.

Check the top and glance, if both system are same then they should have pretty much same processes. Check the processes CPU utilization in top and glance and compare. This may give a hint. Check the network statistics in glance on both systems.

Check if any not needed software is installed on the slow system and if that is hampering the system perfomance.

I would also check for latest patch bundle.

hope this helps.

[Chris Vail]

I'd first look at /etc/hosts, /etc/resolv.conf and /etc/nsswitch.conf. Next ping each box from the other and check response time.

Then look at vmstat, netstat, iostat, top and glance (if you have it). Post some of the results here, and we'll try to help you analyze it.


Chris

[Jose Mosquera]

Hi,

Have you considered the distance factor among the antennas and RF-guns, this does usually cause a high number of retries and traffic?

Rgds.

[Steven E. Protter]

lanadmin -x 0
lanadmin -x 1

Results are of interest.

Messages in /var/adm/syslog/syslog.log

netstat -in

any errors on the machine giving you trouble.


SEP

[Bill Hassell]

Response time on a modern networked computer is a very complicated issue to nail down. As mentioned, the application may be making gethostbyname system calls which depend on the response time of your DNS servers. Since the application seems to be interactive, network issues would only be of a concern if you see massive errors (ie, run landiag to see what's happening) or some badly configured (infected?) PCs are blasting the network with UDP packets.

However, the real question i: where is the delay introduced? Between the source and destination, you have several transmission paths, each with a possible retransmission or delay possibility. If you are using a wide area network (WAN), then short query/response messages will incur significant delays.

But most likely it is an application problem. Start with memory usage. Are you paging to the swap area? If so, then you'll have huge delays in getting some processes to get started again. Only one cure: lots more RAM.

If a single program handles all requests, make sure that the program has queue capability and the stats for the queue can be displayed.

[Michael Elleby III_1]

Thanx guys-

I awarded points based on things that I have already tried or looked at, with little or no indication of what may be the trouble...

I'm still reviewing..

Things that were indicated:

nslookup issue - reviewed the pertinent files (hosts, resolv.conf, nsswitch.conf), and they are the same...

Lan card issue - both primary interfaces on both servers are set to 100FD, auto negotiation off...

UNIX commands - vmstat, netstat, iostat, sar, top and glance all check out.. nothing noticeable..

distance factor - might be issue, if we had never had this problem, and now all of a sudden, we are having it..

Mike E.

[Jeff Schussele]

Hi (again) Mike,

What I was trying to point out is that the problem is likely to NOT be on the HP system at all.
Have you had one of the *delayed* users try to telnet to the other system?
Do they get delays to it as well? If so that clearly points to the client or the client's environment.
Don't discount how poorly the TCP/IP stack is implemented in M$ systems. They could be initiating connections just to have them die & reconnect all over again & that would look like a simple delay to the users. It's true that it might not be name/IP resolution - but that's the leading cause.

Rgds,
Jeff

[Michael Elleby III_1]

Hey Jeff-

Thanx for the info. And I thought to myself that I needed to be a little more clearer...

These two systems sit in separate HA environments (Serviceguard) in separate subdomains, and the telnet logins are actually RF guns that work with the application that is running on the server. But the servers are configured exactly the same

The users were complaining that the response from the usage of the guns were very slow.. That's when I started looking at the network config on both boxes, and although they report to a different DNS server serving their respective zones, running sar and vmstat, iostat and netstat, I couldn't find anything going on...

I thought about reviewing the configuration of the guns themselves...

Mike

[Jeff Schussele]

Well Mike, this is where I check out. I know zip about that media. In fact, you're the 1st person I've ever heard using it.

My extent of knowledge of RF is that refraction, interference & deflection of RF can really mess with broadcast ability. What's different about *that* particular environment?

BUT...like all things, patterns are what seperate every thing. All I can say is look *hard* for them & you're much more likely to find your answer.

IJAP,
Jeff (It's Just A Problem)

P.S. -- THE #1 rule of troubleshooting - WHAT CHANGED?

[Carlos Fernandez Riera]

More on IP adress/Name resolution...



run the command

arp -an

arp -a


If the time to execute each command ( -an should be faster) is not the same i were be sure it is a DNS problem.

Check man resolv.conf and resolver :

retrans value in milliseconds

retry number of retries

I thinked it was a telnet issue too.