Cluster server slow, could different times on the servers be the cause?

Cluster server slow, could different times on the servers be the cause?
ThanksHi
"a" wrote:
> Cluster server slow, could different times on the servers be the cause?
> Thanks
>
I would not expect it, but good practices would have them syncronised. Have
you looked at perfmon counters?
John|||No, I do not have access to this particular server. I have an dataload app
that runs in 6 minutes on a lil ol' PC but it takes 45 minutes to run insert
400,000 records into a db after deploying to the Production Server which has
4 quad processors with 32 GB of RAB and a fiber connection to the SAN. HQ
keeps telling me it's not a hardware issue, it's something wrong with the
code. That is just one of the few hints I have received, the other is that
although the application is not using transactions, there is a long running
transaction that has a lastwaittype of writelog which indicates to me a
possible disk bottleneck.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:556D6AD2-31AA-433F-A5BA-EE1A1AB6B05C@.microsoft.com...
> Hi
> "a" wrote:
>> Cluster server slow, could different times on the servers be the cause?
>> Thanks
> I would not expect it, but good practices would have them syncronised.
> Have
> you looked at perfmon counters?
> John|||I often see developers do stuff on their 'local box' that kill a production
box. Indexes (or not), number of rows in production 5 orders of magnitude
more than local box has, 2000 concurrent users on prod box, ONE on local
box, etc. etc.
If you cannot check perf mon counters on the prod box, or at least get
sp_who run while the load is happening to check for blocking, you will never
know the actual cause of the slowness.
My guess is resource blocking by other users, or a huge number of rows in
production that you didn't mimic on your test box. There could also be
something like audit triggers on production that you don't have either. The
list goes on and on.
--
TheSQLGuru
President
Indicium Resources, Inc.
<a> wrote in message news:%23ml9MjVdHHA.4888@.TK2MSFTNGP06.phx.gbl...
> No, I do not have access to this particular server. I have an dataload
> app that runs in 6 minutes on a lil ol' PC but it takes 45 minutes to run
> insert 400,000 records into a db after deploying to the Production Server
> which has 4 quad processors with 32 GB of RAB and a fiber connection to
> the SAN. HQ keeps telling me it's not a hardware issue, it's something
> wrong with the code. That is just one of the few hints I have received,
> the other is that although the application is not using transactions,
> there is a long running transaction that has a lastwaittype of writelog
> which indicates to me a possible disk bottleneck.
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:556D6AD2-31AA-433F-A5BA-EE1A1AB6B05C@.microsoft.com...
>> Hi
>> "a" wrote:
>> Cluster server slow, could different times on the servers be the cause?
>> Thanks
>> I would not expect it, but good practices would have them syncronised.
>> Have
>> you looked at perfmon counters?
>> John
>|||Hi
"a" wrote:
> No, I do not have access to this particular server. I have an dataload app
> that runs in 6 minutes on a lil ol' PC but it takes 45 minutes to run insert
> 400,000 records into a db after deploying to the Production Server which has
> 4 quad processors with 32 GB of RAB and a fiber connection to the SAN. HQ
> keeps telling me it's not a hardware issue, it's something wrong with the
> code. That is just one of the few hints I have received, the other is that
> although the application is not using transactions, there is a long running
> transaction that has a lastwaittype of writelog which indicates to me a
> possible disk bottleneck.
>
You can use perfmon and DBCC SQLPERF ( WAITSTATS ) in SQL 2000 or
dm_os_wait_stats in SQL 2005 to determine how well the I/O subsystem is
working. A mis-configured SAN can give poor performance, copying a large file
onto the SAN may indicate this is an issue if it takes an abnormally long
time. You could also use the utilities SQLIO or SQLIOSIM to check performance.
You should also check for blocking when running your process.
Check the CPU and Memory usage, the server may not have been configured to
allow processes other than SQL Server to consume large amounts of resources.
Make sure that you know what is normal for your system as well as what
happens when you run your process. It could be that the system had issues
already and your application has exacerbated them.
HTH
John