We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


Why this server so slow

gaofei asked
Medium Priority
Last Modified: 2013-12-23
Now We have a solaris 2.5.1 server which run sendmail,pop3,
http,informix database. but since it worked, it runs sometime slow sometime quick, the web is slow till time out sometime, so does sendmail,pop3. I really don't why and how to deal with it.
Watch Question


   Well .. it's really hard to solve your problem without
knowing the hardware you're running on, the memory. First,
you seems to be running too much stuff on it ... If the
average load on your server is more than 5 ...then I think you
will need to split the load on another server. When it's slow .. try to check how many processes are running ... same for the it's fast. Check which one is taking the most CPU & memory.
   The command "ps" will show you the process, "w" will show you
the current users & load, "netstat" will show you current network
    Performance tunning is a large issue ... of which I cannot
go into details. The commands above will help you understand
which process is taking a huge chunk of your CPU time, and what
make your network slow.
Good luck,
Minh Lai


I have use 'vmstat' to see the cpu and memory resource,but I
think system resource is enough,I also use 'ps' to see the
processes,but the processes are alse not more than that system
can deal with.
because all users are database users not unix users,so there
not so much users.So I don't know why this server so slow much
more,Please give me another answer.

I'm just guessing here, but you say the users of the database are not unix users, so I guess you are using ODBC to access the system.  In my own experience I've seen that once you get more or less two thirds of the users to just log in to the database it slows the whole system down.

What happens is that informix sees the connection and accepts is once the user enters the password (in the case of odbc this is done automatically) and then claims a percentage of the unix kernel resources just in case that user decides to do some work.  What I would suggest is to try something: Get all the users to log out (or do this a night)...bounce the machine and see what happens, what the performance looks like.  And then again get ALL (or most) of the users to just log in to the database, then look at the memory and CPU usage (possibly swap file as well).  If I correct you may see a huge decrease in kernel resources.  Should this be the case I suggest going back to your supplier of Informix and see whether there are any patches available to solve this.


I too run an Informix DB among the many apps on Sol2.5.1 for a large company with a huge load with without any performance  problems. The easiest way to find out stats is pull up a performance meter and set it to log and follow it for any trends. The other thing is if the actual system is fine is that it could be the network. Howe many people log into this and how much are they pulling and through what kind of network device (TBase10, etc). The other thing is that it might be as stupid as that the database needs to be set up for performance. Do you use raw partitions, RAID (and if so what kinds?), or a standard UFS? What is the size of the database? It may need some archiving, compression, or purging... And you might want to take a look at swaping for the DB itself. Another thing is to take a look for a variable (which I can't remember off the top of my head) that is something like MAXTCP. You might be running out the maximum number of network transactions at a time the system can handle per cycle. Take a look at Adrian Cockroft's book on Solaris System Performance Tuning or O' Reilly's book on System Performance Tuning.
From experience running an ODBC database on a Solaris 2.5.1 Sparcstation-5 (64MB RAM), I also had a similar problem prior to installing all recommended patched (up to 1/7/97 at the time the problem arose).  I found informix was subject to the Solaris kernel mutex_enter bug, which caused significant memory leakage (when the initial authentication connection to the database was made)
You can probably test if this is the same situation by hitting the Informix database with rapid authentication requests.

Whilst doing this, watch the system load at frequent intervals (with sar - probably 2 seconds would show a good indication of load).  The processor load should hit 100% reasonably quickly, and stay there even after authentication is complete.  Also monitor swap/memory access, you should find that memory usage jumps rapidly, then appears to drop down quite rapidly.  (Though not all of the memory threads are correctly released).

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
its so annoying when people dont grade questions :)

its so annoying when people dont grade answers :(


but I really don't understang you all, how can I repair this
mutex_enter bug?


but I really don't understand you all, how can I repair this
mutex_enter bug?

Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.