Windows 2008 R2 server, 16G ram. MS SQL 2012, Max server mem set to 12G (not sure if the SQL info is relevant).
I have an exe that has a function which can be run manually (click the button) or via a scheduled task (passing the correct param).
When the task gets run manually, all works fine.
When the task is run as a scheduled task, I get the following error:
RenderEventToBuffer failed because of insufficient memory -122-The data area passed to a system call is too small
** The one thing that might be a hint OR could be a red herring, is that it seems after the sql server is restarted (and much less than it's 12G limit in memory) the scheduled task runs fine, but the error appears once the sql server hits the 12G memory limit.
As I write that, it really does seem red-herring-ish, but I don't know enough to know enough.
Can anyone help me understand what this means and how to solve it?
I do not know what causes this but rebooting the server has fixed this for me across multiple systems when encountered.
Related
I am looking for a way how to analyze what caused this errors in a MSSQL server:
A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 499352, committed (KB): 1024012, memory utilization: 48%.
2021-12-05 18:49:42.63 spid1504 Error: 8645, Severity: 17, State: 1.
2021-12-05 18:49:42.63 spid1504 A timeout occurred while waiting for memory resources to execute the query in resource pool 'internal' (1). Rerun the query.
This is happening randomly (I didn't found a reason why or when or what can cause this) few times in a month. I already set up some monitoring counters (https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/monitor-memory-usage?view=sql-server-ver15) in perfmon but I think this will not solve my problem.
My problem is that I don't know what is causing such SQL memory consumption. I think it is some query from IIS website which is hosted on the same server. It is even worse because it is a production MSSQL server with IIS server and always when this is happening, some admins are going to restart the whole server immediately (because it is PROD and it's need to be working). So I don't have time to look around what is happenning in the server when this occurs. In reality I don't even know (nobody knows) when this will happen again. I need to rely only on historical data. Any thoughts how can I find some reliable information what is causing this?
Server is hosted as VM with this setup:
Windows Server 2019 Datacenter
Microsoft SQL Server 2017 (Maximum server memory (in MB): 32768)
16 vcpus
64 GB RAM
I have a problem with my SSMS. For every 5 minutes of interval Intellisense
is not working. Is there something wrong with my SSMS software or something wrong with the local server.
I won't say it is not working but it is not consistent. Can anyone give me a insight of whats the problem.
I tired Refreshing Local cache(Ctrl+shift+R) with no luck. For next 5 minutes it will work then it wont work.
You can install sqlcompletefree.exe for the Intellisense. It's free version of Sql Server intellisense.
You will get it from the below link
dbForge SQL Complete Express
If SQL server you are connected to is very busy with CPU or IO intensive load, intellisense may be lagging as well. As it is async, you may be happily typing away, but not getting any code completion. I found that due to an extreme case where the host was pinning CPU and SQL server was slow, but ran queries fine, while intellisense did not work at all. As soon as I got the admin to kill the runaway service, intellisense immediately started working again, while "small" query performance hardly changed.
Error logs for our SQL Server instance are gathering a large amount of data (250k records in a month) all day, then all of a sudden stop at roughly the same time of day (9:15pm), though on different days of the week and at seemingly random intervals of days.
This corresponds to other issues on the server: 1) jobs that move files to shares on the database server fail 2) I am not able to access the server via any method (tried RDP and SSMS). Once the servers are rebooted, SQL Server comes up and SQL Server error logging resumes.
Windows Event Viewer doesn't show any notable error messages for System (the other event logs have wrapped already).
The error logs are being written to the D:\ drive, which has over 100GB free currently. The error log files are in the range of tens of megabytes.
Appreciate any ideas on what might have caused this or how troubleshoot it. Thanks!
The cause appears to have been a corrupted maintenance plan. I discovered this by correlating the timing of the lock-up to the times the maintenance plan was running. The lack of logging made this difficult to confirm. Guessing that at least some parts of it ran normally, but got rolled back on restart.
The current fix was to disable the maintenance plan and replace it with a collection of jobs that do the same tasks. I will likely recreate the original maintenance plan if the server remains stable for another week or two. If we stay stable past that point, it should solidly confirm the maintenance plan as the source of the problem.
I am working on a Flex application that is connecting via Flash Remoting to ColdFusion 8 with a SQL Server 2005 database. Most of the time, everything runs fine. However, from time to time, it will take an exceptionally long time for SQL Server to return data from a stored procedure call to ColdFusion; returning data from CF to Flex is very fast. When this happens, I can run the exact same call from Management Studio on the SQL Server or a ColdFusion page on the CF server and get results immediately. The most recent occurrence of the issue took about 90 seconds to return data to CF. During the 90 second window, I was able to run the stored procedure in Management Studio several times.
I have tried using different drivers and this doesn't seem to matter. I have also kept an eye on server performance and haven't noticed anything unusual while this is happening. Has anyone seen this behavior before? Any ideas as to what I should be looking for.
While it's working slowly, can you run "sp_who2" against your SQL Server? If it's a blocking issue, you'll see rows that have a value in the "BlkBy" column, meaning that they'r waiting for another process to complete before they can continue.
If that's the case, then there's other troubleshooting to do so you can figure out what's causing the blocks. This article provides an overview of locking and troubleshooting blocks. If that's your issue, please update your question and add more details, and we can help you go from there!
Are you absolutely sure that the query being run in the sp is the same every time? For example, is it possible that when it slows down, the query has a different sort order? Possibly 9 times out of 10, the query returns quickly, and that 10th time is slow b/c the data you're getting is being sorted by some column that isn't indexed?
In these situations, I'd try to have a SQL Trace set up (using sql profiler) and let it run for a while. Once the situation happens, let it run through, and then analyze the trace. Confirm beyond doubt that the query being run is the same as other executions of the same sp
I have RO access on a SQL View. This query below times out. How to avoid this?
select
count(distinct Status)
from
[MyTable] with (NOLOCK)
where
MemberType=6
The error message I get is:
Msg 121, Level 20, State 0, Line 0
A transport-level error has occurred when receiving results from the server (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
Your query is probably fine. "The semaphore timeout period has expired" is a Network error, not a SQL Server timeout.
There is apparently some sort of network problem between you and the SQL Server.
edit: However, apparently the query runs for 15-20 min before giving the network error. That is a very long time, so perhaps the network error could be related to the long execution time. Optimization of the underlying View might help.
If [MyTable] in your example is a View, can you post the View Definition so that we can have a go at optimizing it?
Although there is clearly some kind of network instability or something interfering with your connection (15 minutes is possible that you could be crossing a NAT boundary or something in your network is dropping the session), I would think you want such a simple?) query to return well within any anticipated timeoue (like 1s).
I would talk to your DBA and get an index created on the underlying tables on MemberType, Status. If there isn't a single underlying table or these are more complex and created by the view or UDF, and you are running SQL Server 2005 or above, have him consider indexing the view (basically materializing the view in an indexed fashion).
You could put an index on MemberType.
Please check your Windows system event log for any errors specifically for the "Event Source: Dhcp". It's very likely a networking error related to DHCP. Address lease time expired or so. It shouldn't be a problem related to the SQL Server or the query itself.
Just search the internet for "The semaphore timeout period has expired" and you'll get plenty of suggestions what might be a solution for your problem. Unfortunately there doesn't seem to be the solution for this problem.
Do you have an index defined over the Status column and MemberType column?
how many records do you have? are there any indexes on the table? try this:
;with a as (
select distinct Status
from MyTable
where MemberType=6
)
select count(Status)
from a
My team were experiencing these issues intermittently with long running SSIS packages. This has been happening since Windows server patching.
Our SSIS and SQL servers are on separate VM servers.
Working with our Wintel Servers team we rebooted both servers and for the moment, the problem appears to have gone away.
The engineer has said that they're unsure if the issue is the patches or new VMTools that they updated at the same time. We'll monitor for now and if the timeout problems recur, they'll try rolling back the VMXNET3 driver, first, then if that doesn't work, take off the June Rollup patches.
So for us the issue is nothing to do with our SQL Queries (we're loading billions of new rows so it has to be long running).
This is happen because another instance of sql server is running. So you need to kill first then you can able to login to SQL Server.
For that go to Task Manager and Kill or End Task the SQL Server service then go to Services.msc and start the SQL Server service.
While I would be tempted to blame my issues - I'm getting the same error with my query, which is much, much bigger and involves a lot of loops - on the network, I think this is not the case.
Unfortunately it's not that simple. Query runs for 3+ hours before getting that error and apparently it crashes at the same time if it's just a query in SSMS and a job on SQL Server (did not look into details of that yet, so not sure if it's the same error; definitely same spot, though).
So just in case someone comes here with similar problem, this thread:
https://www.sqlservercentral.com/Forums/569962/The-semaphore-timeout-period-has-expired
suggest that it may equally well be a hardware issue or actual timeout.
My loops aren't even (they depend on sales level in given month) in terms of time required for each, so good month takes about 20 mins to calculate (query looks at 4 years).
That way it's entirely possible I need to optimise my query. I would even say it's likely, as some changes I did included new tables, which are heaps... So another round of indexing my data before tearing into VM config and hardware tests.
Being aware that this is old question: I'm on SQL Server 2012 SE, SSMS is 2018 Beta and VM the SQL Server runs on has exclusive use of 132GB of RAM (30% total), 8 cores, and 2TB of SSD SAN.