1. On the server in question we don't have any access. Just SQL Server
2. I'll try the updated drivers.
8. SQL is not on the web server. Both boxes are separate servers.
9. Our names are not FQDN but are not IP addresses either. We just use the server name (sql-server). I'll play with the host file.
______________________________________________________
<file:///E:/EUColor.gif>
Bill Grover
Manager, Information Systems Phone: 301.424.3300 x3324
EU Services, Inc. FAX: 301.424.3696
649 North Horners Lane E-Mail: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
Rockville, MD 20850-1299 WWW: <http://www.euservices.com/> http://www.euservices.com
______________________________________________________
-----Original Message-----
From: Mark A Kruger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 31, 2004 9:41 AM
To: CF-Talk
Subject: RE: 100% CPU
Bill,
I went through a similar process with a client of ours. We did several
things to mitigate this issue.
1. Eliminate Access dbs. If you have anything running on Access get rid of
it.
2. Make sure and use the JDBC Merant 3.3 drivers for SQL - this is an update
from 6.1.
3. Check out long running db requests - maintenance tasks, utility tasks,
data imports, exports and dumps ect. Create a separate datasource for
these, restrict the number of connections and deselect the "maintain db
connections" for that db resource in cf admin.
4. Fiddle with the JVM maxperm memory, and heap sizes. Try to get them
large enough so that the heap is not being constantly resized and garbage
collection is efficient. There are a ton more JVM settings depending on the
JVM you are using.
5. Use Perfmon to figure out which resource is hanging.
6. Consider increasing the process isolation in IIS for the application - it
can tell you if IIS is having conflicts with other processes outside the ap.
7. Check the web logs for a burst of http requests at the point of failure.
One customer I know created a dynamic publishing system with constantly
updated content - then he used google adsense to serve ads and make himself
money. But every time a new page was published (new to google) the
googlebots attack to figure out which ads to serve. Since his server was
near capacity this sometimes surfaced as a denial of service type attack
(much like you are seeing) - and since many of his pages were driven by
database calls it looked like a possible db problem - or connection issue
etc.
8. Consider moving the SQL server Off of the web server.
9. Make sure and use a FQDN for the server name in the database
administrator. In other words, don't use "127.0.0.1" or any other IP
address. use "sql.mydomain.com" type syntax. In fact, put the domain in the
HOST file if you have a default win server configuration. Windows will check
the host file first to resolve the domain - which saves a dns request. JDBC
will attempt to resolve an ip into a domain name using reverse lookup before
making a connection. In many cases this results in a lengthy initial
connection request. Having a guaranteed resolution to a flqn (a la the host
file) eliminates this problem.
That's my short list - anyone else?
Mark A. Kruger, CFG, MSCE
www.cfwebtools.com
www.necfug.com
http://blog.mxconsulting.com
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
