I have a rather complex Linq-to-SQL query which when run locally or from the AAT environment takes about 2-3 seconds. That's ok-ish. The problem I've got is on the QA and Production servers where the query takes 2-5 minutes(!). When profiling it looks like EF CF generates different SQL in these environments.
We are targeting .net 4.0 using EF 5(4.4)
A quick recap:
Operation takes 2-3 sec in local/AAT
Operation takes 2-5 minutes in QA/Prod
Databases have the same data
It does not matter which database I connect to or which environment I connect from, the performance issues stay the same.
Catching the generated SQL and running it through SQL Management studio gives the same execution times.
It seems like the biggest difference in the queries is that one of them uses more outer joins and the other uses more inner joins.
Does anybody have a clue to what's going on?
EDIT: Queries generated locally(22 sec) and on server(3min 45sec)
Related
I am having the vfp application and its very complex . I am using the SQL as database , Application responding very late in some scenarios.
How to improve Performance in VFP application ?
Any tips?
There are a few things you need to consider;
Firstly when you run your query in a tool such as SQL Server Management tool, how long does the query take to run?
If it takes 5 minutes to run, then it will take a minimum of 5 minutes to get your data back.
Secondly, if the data you are retrieving is large, then this data has to be transferred from SQL to VFP before you can do anything.
Not much else can be said without an example.
My Entity Framework is set up to emit the SQL generated, followed by the time taken to run the query, to the Output pane.
When I run it locally, the EF query takes .064s (as can be seen in the Output pane), and the SQL (when run by itself in Management Studio) takes about the same. In production the EF query takes .660s, yet the SQL generated only takes .157s.
There are about 50 rows returned. All the other EF queries are running at the expected speed.
What can cause the EF to take so much longer to run than the SQL it generates?
Thank you for any ideas.
The simplest way to figure out why queries run differently when called from different locations is to check the execution plans for both of them. From SSMS it's simply a case of including the plan in the output. For a live SQL Server you can use SQL Profiler.
When you have both plans, compare them and figure out the differences.
One example when a query runs differently is the ARITHABORT setting. Your app probably connects to SQL Server with this turned off whereas in SSMS it is on. This may cause it to use a different execution plan.
I'm running a 32 core SQL Server Box. Which also runs a SISS Server, where SISS packages are stored and run.
The load on the database is very low, nightly updates, a handfull are tables updated during daytime, and otherwise is just a lot of select statements. Typical DW with a frontend that caches data.
My issues is that when I run a SISS package, in the studio, then it executes within a hour. But if I run it on the SISS Server it runs for hours. The package basically aggregates data from various tables, and places it in one table. Other package of other types, also run very slow when run from SISS Server.
CPU usage is never above 7%, memory is at 29gb of 32 on the server.
Is there a way that I can prioritize CPU away from the SQL Server and over to SISS Server?
I believe CPU priotization is the issue, but I might be wrong.
When SSIS runs out of memory it will typically slow down a lot before it fails, as it will start writing and reading temp files for some operations. I suspect this is your problem.
To avoid this I would reduce the maximum Memory allocated to the SQL Server Database Engine, e.g. to 8GB. Obviously you need to consider potential impacts on other SQL Server Database Engine operations, but it usually does surprisingly well with less Memory.
PS: you are admirably consistent with your mis-spelling of SSIS ... :-)
I recently moved my .NET development from an older Core2Duo 2.93 GHz PC to a new Core i7-3820 3.6 GHz machine. No changes were made to the project code or database layout. Both machines use the same SQL Server 2012 Express with Advanced Services (not LocalDB).
I observe a significant slowdown of INSERT INTO commands: what used to take 1-2 milliseconds per row on the old machine, now takes 8-9 milliseconds on the new one. The only fix I was able to find was to use multiple row inserts in one command, which seems to spread the overhead of the command over many rows. As in SQL Server 2008 R2, in SQL Server 2012 the limit for the number of rows in one such command is 1000:
http://msdn.microsoft.com/en-us/library/dd776382.aspx
However, the multiple row workaround is not applicable to all scenarios; e.g. table adapter updates that go row by row and take a long time to complete.
Has anyone experienced this problem? How would I go about resolving it?
The cpu is definitely better but what about the disk io? Inserts obviously rely on that subsystem.
It happens I was just reading this article http://www.altdevblogaday.com/2012/05/16/sql-server-high-performance-inserts/
It seems table value parameters can increase performance dramatically
The comments lead to the following page which has some impressive numbers.
In the comments http://florianreischl.blogspot.de/2012/03/performance-comparison-of-sql-server.html
I've yet to use this myself but tvp seem the way to go to pump data from a client to sql server if you have 2008 or up.
to be honest, writing records one at a time is ALWAYS slow.. CONSIDER - if it fits within your architecture - to write the rows to a text file and then BULK INSERT it, and your performance will go up tremendously.
I have a big stored procedure on a SQL Server 2008 Express SP2 database that gets run about every 200 ms. Normal execution time is about 50ms. What I am seeing is large inconsistencies in this run time. It will execute for while, say 50-100 times at 40-60ms which is expected, then seemingly at random the same stored procedure will take way longer, say 900ms or 1.5 seconds to run. Sometimes more than one call of the same procedure in a row will take longer too.
It appears that something is causing sql server to slow down dramatically every minute or so, but I can't figure out what. There is no timing pattern between the occurences.
I have the same setup on two different computers, one of which is a clean XP Pro load with no virus checking and nothing installed except SQL server.
Also, The recovery options for all the databases are set to "Simple".
I would suggest breaking out applicable sections into their own stored procedures; there is only one query plan cached per batch.
It looks like my problems happen simultaneously with the SQL Server Plan Cache Object Counts hitting 999 and resetting.