July 8, 2014 at 5:57 am
Here some data of our vm:
NUMBER OF VM: 1
RAM: 16 GB (static)
CORES: 4
HD: IDE, 150 GB.
Filesize (mdf): 5.92 GB
Filesize (log): 3.93 GB
The capacity of the cpu (VM) during the query is runnig is approx. 2 %.
I guess, the reason is not the CPU for being that slow. 😉
Maybe, we should choose another network configuration, because part of the work is done by the client.
Any idea ?
July 8, 2014 at 8:10 am
StephenNL (7/8/2014)
Here some data of our vm:NUMBER OF VM: 1
RAM: 16 GB (static)
CORES: 4
HD: IDE, 150 GB.
Filesize (mdf): 5.92 GB
Filesize (log): 3.93 GB
The capacity of the cpu (VM) during the query is runnig is approx. 2 %.
I guess, the reason is not the CPU for being that slow. 😉
Maybe, we should choose another network configuration, because part of the work is done by the client.
Any idea ?
firstly - assuming you have no other workloads on that machine kicking CPU significantly over 25%, I would cut to 1 CPU. If possible, I'd also consider whether this could be consilidated with other servers. Too many cores on a VM can actually degrade performance.
I'd also get your VMWare admin to swear blind you're not being ballooned. If you're new to SQL Server on VMs I'd have a look at these;
http://www.brentozar.com/sql/virtualization-best-practices/
also Jonathan Keyannes on this issue on PluralSight (not free this one $29 pcm) and also Brent's paid for VM and SAN training video ($400 ish IIRC) if you're feeling flush or can get the company to swing for it. You are going to find stuff in there that's going to surprise your VM/SAN admin(s). As mine have found out.
It's NOT like running a File Server, SQL Server "Doesn't Play Nice With Others" on these systems
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
July 9, 2014 at 8:33 am
1 - check the size of your tempdb.
This is usual vilain.
2 - drop and recreate the view and maybe the envolved indexes.
No logic, ok, but works.
July 9, 2014 at 10:41 pm
We do not use VMWare, but Hyper V.
July 9, 2014 at 10:48 pm
Dear Augusto,
once again, the reason for the database being that slow is caused by a wrong Hyper-V configuration.
July 10, 2014 at 4:14 pm
StephenNL (7/9/2014)
Dear Augusto,once again, the reason for the database being that slow is caused by a wrong Hyper-V configuration.
While there are differences between visors, the basic concepts are the same = no ballooning (other than stuff you just don't care about), don't assign too many cores, make sure the storage is fast enough.
Also - we currently have no info on what's wrong
read this, and the links, get an idea where Paul's coming from then run te query to see what your main waits are and post
http://www.sqlskills.com/blogs/paul/wait-statistics-or-please-tell-me-where-it-hurts/
also - try running sp_blitz, this may also help - run it, check the links, post te results of anything you don't, or are not sure you, understand
http://www.brentozar.com/blitz/
This won't solve anything, but it's a start.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply