Hello,
We have resolved our SQL server CPU issue and I thought i'd post the
resolution here in case anyone is interested.
We switched from Windows server 2008 to Windows server 2008 R2
(although this didn't make any difference to performance, it was
simply that our database server got upgraded
Hi Charlie,
I have checked our client variables pages and there aren't any DSN's listed
(just the default option of registry selected), I've checked the
cfapplication tag for the site too and it uses the default (registry).
I'll log full query stats for a day anyhow and see if it shows us
Ok, yes, then if there is no DSN listed in the client variables page, that
confirms
that you cannot possibly be using them (whether intentional or otherwise). Glad
to see
that ruled out.
The query logging (and analysis) would seem to be the useful next step-though
again,
100% CPU in the DB
Thanks Charlie,
It is SQL running on its own box, I'll get the DBA to check what else is
running (such as antivirus).
I'm pretty sure he checked the event logs and there was nothing odd there,
he pretty much said that the query activity is normal, just that there is a
very high volume of queries
Barry, I would just wonder if perhaps you're suffering the death of a thousand
cuts,
where it's not that you have any (or many) long-running (or even moderately
long-running queries), but instead maybe lots (and lots) of small-running
requests.
Just something to consider.
And as for using FR,
It is looking like a 'death of a thousand cuts' issue as you put it, and we
do have a plan if that is the case :)
We have limits on the JDBC stuff in fusionreactor because we haven't really
needed to use it. Our DBA is fairly certain that there isn't a set of, or a
specific query that is causing
Well, as far as having the limits because you've not needed to use it, I'm
proposing
that now's the time. :-) And after capturing that data, then look in the JDBC
logs
(which are not enabled by default-again, controlled in the jdbc settings page).
It's
going to be a lot of data, but you can do
As for the client settings / DSN.
What is the recommendation then?
We have ours set to registry.
Though since we're on linux and we don;t have a registry - I am guessing it
using some sort of text file but it is only a guess!
Gavin Beau Baumanis
On 29/11/2010, at 2:39 PM, charlie
Hi Gavin,
This Adobe ref says:
Choosing a client variable storage method
By default, ColdFusion stores client variables in the Registry. In
most cases, however, it is more appropriate to store the information
as client cookies or in a SQL database.
ref:
Yes, that's right: if it's set to registry (and any code is set to enable
ClientManagement and doesn't specify a different ClientStorage, both settable in
CFAPPLICATION or application.cfc), then yes, the i/o is to a file that
simulates the
registry (called registry.db, which I think is in the
Hello Gavin,
Here is another Adobe reference on client variable (I could not find
it before when I posted other and got side tracked).
Details:
Adobe recommends that you do not store client variables in the
registry because it can critically degrade performance of the server.
If you use the
Barry, here are some other thoughts I've not yet seen mentioned. (Like you, I am
behind on this thread due to vacation, though in my case it was my time there in
OZ-Melbourne, specifically-the past two weeks. Great time. Thanks to all
involved and
those who I met while there.)
As for your
Hey guys, thanks for all the feedback, I'll pass on those ideas to our DBA
:)
I haven't replied earlier sorry because I've been on holliday up in Auckland
to see U2, but we'll follow up some of the ideas here on Monday at work and
I'll let you all know if we manage to fix the problem :)
Thanks!
Morning Barry,
Did any ot those suggestions help sort your problem out?
Briefly I think there are:
- yes to VM but more cores (which you already raised)
- no to VM
- packetsize setting match
- alternate JDBC driver
To add to JDBC driver change, you could try the free type4 SQL driver
from
Good clarifications Kai. Always nice to cut through some of the
marketing spin.
Carl, swapping out your JDBC drivers would be a fairly small amount of
effort to see if it gives you any performance improvements. You could
just run your regression tests over your app after the swap and see
the
On 25/11/2010 12:59, Pat wrote:
Good clarifications Kai. Always nice to cut through some of the
marketing spin.
Carl, swapping out your JDBC drivers would be a fairly small amount of
effort to see if it gives you any performance improvements.
Are we drifting off-track? The OP complaint was
Hello Barry,
Some people say to obtain maximum performance the JDBC driver should
transmit data
to the database server in packets that are equal in size to the
maximum packet size configured on the database server.
For SQL to check packet size:
-SQL Management Studio (connect to server etc)
I haven't checked in a while but the jtds driver (http://
jtds.sourceforge.net/) used to be faster than default JDBC driver CF
come's with for MSSQL
On Nov 24, 7:13 am, BarryC barrychester...@gmail.com wrote:
Hi,
We have an issue currently where our Microsoft SQL server runs close
to 100% CPU
Hello Pat,
I use the divers built in CF. The JDBC divers in CF8/9 are type4. I
see datadirect has released jdbc type5 drivers:
http://web.datadirect.com/products/jdbc/index.html
Regards, Carl.
I haven't checked in a while but the jtds driver (http://
jtds.sourceforge.net/) used to be faster
Just a quick note to make a few things clear:
- the type doesn't reflect on the quality. E.g. a type 4 driver is not better
than a type3 driver and a type5 driver not necessary better than a type4
driver. They just do things in different ways. I just want to avoid that the
type is seen as a
20 matches
Mail list logo
