We have an ASP.net MVC website running in a Webecs.com virtual dedicated server with 1Gb CPU, 3 Gb of RAM and using a SQL Server Express database within the same server. Now and then, the database is giving a timeout error that is fixed temporary by executing sp_updatestats stored procedure.
Initially, we thought it was a RAM problem and we raised the RAM in the server to the current 3Gb amount. Even though the problem is less frequent now, it is still happening when the traffic in the website increases and more queries are executed. We have been monitoring the CPU and RAM usage and it does not seem to be the problem, CPU is around 30% with some picks up to 90% and RAM is around 80%.
We have the exact same website running in a different, more potent server with SQL Server 2008 R2 and is working without problems.
Any ideas what’s happening here?
Edit
Queries are of a normal size, nothing too big.
We have profile it with glimpse.
There is not n+1 queries, there is an average of 10 queries per page and sometimes the timeout happens in the login page where there is only one query.
The database isn't too big either.
Related
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 will preface this by stating we are using MS SQL Server 2008 R2.
We're having issues when our database backups are running SQL Server takes all of the available memory and never releases. Our current high watermark of memory usage is about 60%. When the backup job runs it goes to 99% and never releases unless we reset the SQL service. This leads me to 2 questions:
Dealing with memory allocation, Is there a way to accurately limit memory usage of SQL Server? We are limiting the "Maximum server memory" value to 85% but in consistently exceeds that value.
What is the best method of backing up the database? We are currently relying on our provider to maintain the database backups and it seems like the "home grown" method they use through a stored proc and commands is the cause of the memory issues but it is working for other customers of theirs. Should we look at using Maintenance Plans as a replacement?
Any help with this would be great.
Is there a way to accurately limit memory usage of SQL Server?
Yes there is. How to: Set a Fixed Amount of Memory (SQL Server Management Studio)
Use the default settings to allow SQL Server to change its memory
requirements dynamically based on available system resources. The
default setting for min server memory is 0, and the default setting
for max server memory is 2147483647 megabytes (MB). The minimum amount
of memory you can specify for max server memory is 16 MB.
What is the best method of backing up the database?
You can get the answer here: Select the Most Optimal Backup Methods for Server
I currently have a SQL Server 2005 set up and has been running successfully for quite a long period of time without any issues.
As of this morning our website applications have been attempting to perform udpates on various rows. However, every time an update happens the data never gets updated in the database.
Our application's code hasn't been changed in any way, and there appears to be no errors of any kind.
Is there anything in SQL Server that can prevent updates from being performed on a database? Can the size of transaction logs prevent data from being updated on a SQL Server database? Or anything at all that can cause this strange behaviour?
We had similar behaviour on one of our servers and it was due to the log file being on a hard drive that had run out of disk space - so worth checking that.
Also check that the Autogrowth limits haven't been reached:
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.