From: Dennis Snyder (dsnyde27@jhmi.edu)
Date: Tue Jul 18 2006 - 15:45:41 EDT
Hello to all gurus that be:
I think I may have a stumper for all you Solaris geniuses out there..... I
sure hope not....
Symptom:
SSH'ing into Solaris 8 system (with latest patch cluster in place) and running
an X app feeding back to an Exceed 7.x client via X forwarding results in 3
processes: The app process ('hide' in this case), olwm, and olwmslave. The
olwm process starts to use more and more cpu utilization until finally the cpu
is pegged at 100% (0.0% idle, ~70% kernel, ~25% user, and ~5% iowait with all
of them fluctuating but still occupying 0.0% idle) - with only one client it
looks like it would take days for the olwm process to climb enough to become a
complete processing hog.... but when you have 50 to 200 clients logging in...
these processes can bring a server to its knees in less than an hour (3
clients can bring the server to 40% utilization in less than 5 minutes and it
continues to slowly climb)
So! What the heck is going on?
We contacted the vendor of the X app and this is what they had to say:
*--Vendor speak here------
Our developers have concluded that the reported behavior is an OLWM problem
and not Exceed. They have also provided a thorough explanation of the
resulting behavior.
With "Allow Clients to Modify Keyboard Mapping" deselected the CPU usage is
occurring because Exceed is maintaining control of the keyboard map denying
requests from OLWM such as modifying the keycodes. OLWM continues to repeat
the requests therefore CPU usage is observed.
With "Allow Clients to Modify Keyboard Mapping" selected Exceed will turn over
control of the keyboard map to OLWM and therefore the CPU usage is not
observed resulting in the behavior where F1 sends 0xFF6A. The F1 key is not
inoperable OLWM is instructing Exceed to send a different value then what the
application is expecting.
Exceed is not breaking anything in fact it is functioning as designed.
You have to determine if you can configure OLWM so it will not modify the F1
key or modify the application so that it will accept 0xFF6A as requested by
OLWM to perform the F1 function .
*-- snip!------
OK... so now I have some sort of understanding as to what's going on.... is
there a way to configure olwm to not modify the F1 key mapping? and if so,
where? What's nice is that all client sessions are under the same login ID...
so if this can be modified through a .dtconfig or something in this user's
home directory or since it needs to be global anyway under /etc/whatever -
that would make it MUCH simpler than visiting over 1000 Exceed clients to
change one stupid setting.... though I have a feeling that that could be the
only recourse.....
Any ideas from the field?
thanks for any and all suggestions...
Denny Snyder
Systems Engineer, IT - JHMCIS
Mt. Washington, Davis Bldg, Suite 3110C
5801 Smith Ave.
Baltimore, MD 21209
Desk: (410)735-7613
Cell: (717)586-5294
dsnyde27 at jhmi dot edu
AIM: wolverine9827
YahooIM: wolverine9827
Quote of the Month: "The brain is a wonderful organ. It starts working the
moment you get up in the morning and does not stop until you get into the
office." - - - Robert Frost
Totally useless Trivia: Cats average 16 hours of sleep a day, more than any
other mammal.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:40:25 EDT