Xsun Process is a CPU Hog on Solaris 2.6 5/98

[scb]

<br>INITIAL PROBLEM DESCRIPTION: <br>&nbsp;<br>Running Solaris 2.6 5/98 on Ultra Enterprise<br>4000 (8 167-MHz CPUs, 2-GB memory) and Oracle<br>v8.0.4/.5. What would cause the Xsun process<br>to hog CPU resources after logging out from<br>the console, which is a 17-inch entry color<br>monitor attached to TGX card on Graphics I/O<br>board? When not logged in (doesn't matter if<br>console is powered on or not or if it's in<br>power standby mode) and do a 'ps' via a<br>telnet session from another system, the<br>number in the TIME column grows very quickly.<br>ProcTool, Top, and UCB's 'ps' show it's<br>taking 12+ percent of the CPU (1/8th of<br>CPUs). Logging in and then out on the console<br>device zeroes everything out for a while<br>until the problem is noticed again that day,<br>the next day, or the next week, or when<br>system performance degrades to the point that<br>users complain about slow response times.<br>That's assuming you can get the console<br>device to even wake up. When the problem<br>occurs, the console I/O and display is VERY<br>slow and it takes forever to login. Usually<br>the device is blank and stays in standby mode<br>(amber LED on or green LED slowly flashing).<br>The console device is rarely used, maybe once<br>or twice per week. <br>&nbsp;<br>LATEST PROBLEM DESCRIPTION: <br>&nbsp;<br>The Oracle production database was moved from<br>the E4000 to a new E6500 with the latest<br>patch cluster. It is running Oracle v8.0.6.<br>This system was running in a test mode prior<br>to going live. Now that it is the production<br>server, it too is experiencing the exact same<br>Xsun problems. The only thing that has<br>changed on it is that more users are<br>connecting it via SQL*Net than during the<br>testing phase. It appears that the Xsun<br>problem occurs during heavier load, over 100<br>users, but I can't confirm this because<br>sometimes it does not have the problem even<br>with over 110 SQL*Net connections.<br>Performance isn't really a problem since the<br>E6500 has 12 400-MHz CPUs and 12-GB of<br>memory, but I'd like to know why the Xsun<br>process takes 8.33% of the CPU (1/12th) and<br>I/O craws, if at all, on the graphics console<br>when this occurs. This system has the newer<br>17-inch color monitor and the Creator3D<br>graphics while the older E4000 has TurboGX.<br>&nbsp;<br>Thanks for any help.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>&nbsp;<br>

 

[AndyBo]

First thing I would do is make sure that your system is fully up to date on the latest patches.&nbsp;&nbsp;(Always a good idea, even if it doesn't solve your specific problem.)<br><br>The next thing I would do is just disable Xsun.&nbsp;&nbsp;You say that you only use the console a couple of times a week, so I can't see this being a problem.&nbsp;&nbsp;It also sounds like this is a live production server, so the last thing you want running is a resource hungry graphical desktop that you never use.<br><br>To stop the graphical desktop, login as &quot;root&quot; and run:<br><FONT FACE=monospace><br>sh /etc/init.d/dtlogin stop<br></font><br>Next, go to <FONT FACE=monospace>/etc/rc2.d</font> and remove <FONT FACE=monospace>S99dtlogin</font>.&nbsp;&nbsp;This will stop the graphical environment from restarting the next time you reboot the server.<br><br>You'll then be left with a text mode console, and your Xsun resource problems will have gone away.<br><br>Hope this helps.

 

[mingx98]

you need patches

 

[OpenSys]

I'm pretty sure I have seen this on SunSolve, I think it's a GUI problem and the recommendation is, as Andy says, to turn off either CDE or OpenWin

 

[OpenSys]

I have done a little thinking on this and I believe that the ultimate fix here for me was that the help dBase had to be resorted, something about a daemon running perinantly trying to find something in the dBase causing this problem with the CDE. BUt I must admit, I didn't find the SunSolve entry that I was sure was there <shrug> Go figure..!

 

[scb]

&quot; So Doc, it hurts when I lift my arm up over my head. What should
I do?&quot;

&quot;Don't lift your arm up over your head!&quot;

&quot;Thanks a lot, Doc. Now why didn't I think of that? I guess that's
why you make the big bucks.&quot; ;-)

I was hoping for a better answer than to not use a utility or program
that's *supposed* to work. Geez, I can hear the support calls now:
&quot;Please, Mr./Ms. Sun Support Person, Solaris 8 isn't working on my
new Enterprise 6500, what should I do?&quot; ...

Sometimes you need to use GUI-based tools and applications.
Sorry, but simply not using them because it &quot;hurts&quot; isn't the answer.

The systems were already and still are fully patched. That was the
first thing we tried (naturally). We're still having the problem with Xsun
on our system(s!). If you don't know of a particular patch that will
solve someone's problem, then don't post a blanket reply that a patch
is the answer.

OpenSys, what help database are you referring to and how do you
resort it?

Any other ideas besides to simply not use the Xsun/Dtlogin?

Thanks,
scb

 

[AndyBo]

Running X full-time on a server has long been perceived as a &quot;no-no&quot; for exactly the reasons you described - it's a resource hog! Those resources are better used elsewhere, such as serving the actual applications on the server. Sure, occasionally you need to run things in a graphics window, so that's when you fire up X. As soon as you've finished, shut X down again.

Alternatively, get an X server running elsewhere on the network (ie, a Windows PC?) and run the apps across the network. This way, the server is not taking the hit running the whole X environment.

Final option: Get a much bigger server. This way you'll have more resources to give to X and the CPU usage will drop way down. It will cost you though...

At the end of the day, X is working OK. It just takes up a lot of system resource. You either accept this and take the hit, or you run it when needed and take a temporary hit, or you don't run it at all. My favoured option is the third one. Just don't run it. Let the servers serve, and leave the pretty pictures to certain other OSes.

 

[scb]

You mean a Sun Enterprise E6500 with 12 400-MHz
CPUs (8-MB ecache each) and 12-GB of RAM isn't a
big enough server to run a simple lousy GUI and an
Oracle RDBMS app at the same time?

You seem to miss the point - it's SUPPOSED to work.
Regardless of the size of the server. Period. It's not
working in my case, on multiple servers (E4000, E4500,
E6500), with different models of graphics cards and
monitors, different version of Oracle, all with the latest
Solaris and Oracle patches. As soon as some strange
threshold is met (user connections via Net8, Oracle
load, CPU load?) the Xsun process for the console
device decides to start hogging one of the 12 CPUs. It
does not matter if the console is in use at the time -
you don't even have to be logged in or using a GUI
app. Making the connection remotely via dtlogin does
not have any problems. Stopping and restarting dtlogin
helps initially, but Xsun quickly becomes degraded
again as soon as or as long as the obscure threshold is
met. Overall, even when the Xsun process is going
bonkers and not allowing any I/O on the console
device (this is the ONLY device that is being effected
by the Xsun process going belly-up), the system is
running at 83-97% idle with plenty of horsepower and
memory to spare. We're only talking about 300 users
connecting to the database at any one time. That's
hardly a load too heavy for this server, or even a much
smaller server, to handle. What's going to happen to
this thing when it starts serving the 1300 users it's
been configured to ultimately handle?

Does any of this seem out of the ordinary to anyone
besides me?

scb

 

[mbitto]

SCB:

What is the patch level of the machine? There is usually a number of patches that relate to the Xsun process. You are right, technically you have enough horsepower to run Xsun, but you'll more than likely need to update the patches.

 

[OpenSys]

I'll keep looking for the SunSolve entry I found previously, but as I said I am afraid I couldn't find it again and it has been quite sometime since I saw this problem... Sorry previous posts were not particularly helpful, but I am getting old and my mind isn't always with the rest of my body...

oddly enough, I seem to remember that I saw this on an Ultra10 only running a small Oracle 7.3.3.0 dBase with a Robotic Library Control Software.

 

[OpenSys]

Hopefully, this is it.. hope it helps, or I'm fresh out of idea's......

The rpc.ttdbserverd process increases dramatically whenever someone logs into
CDE/Openwindows through the dtlogin screen.

No errors are indicated anywhere. Killing the rpc.ttdbserverd process helps
to bring the system back to normal, but the process is restarted again when
logging back out and in just because that daemon is necessary for starting
the ttsession process.

Problem Solution

The problem is as indicated in bugid 4017415. Two things need to be done:

[1] Increase the number of file descriptors for the system. To do this, edit
the /etc/system file and put the following two lines at the end of the file:
set rlim_fd_cur = 128
set rlim_fd_max = 1024

[2] Clean the tooltalk database. Some users said that they had to clean out
the tooltalk databases a couple of times before the problem went away.

To do this, type the following commands:
[a] /etc/rc2.d/S99dtlogin stop <--- this will stop the dtlogin process
df -kF ufs | awk '{if (NR>1) print $6 &quot;/TT_DB&quot;}' <--- this will find all TT database files
[c] rm -rf `df -kF ufs | awk '{if (NR>1) print $6 &quot;/TT_DB&quot;}'`
<--- remove all those database files
[d] /etc/rc2.d/S99dtlogin start <--- start the dtlogin process


After doing all this, reboot the system.
[sig][/sig]

 

[bigscouse]

scb,

chill out man, people are only trying to help.
Have you spoken to Sun abour this issuew if so what was there response?

[sig]<p>Ged Jones<br><a href=mailto:gedejones@hotmail.com>gedejones@hotmail.com</a><br><a href= > </a><br>Top man[/sig]