sql server 2008r2 standard - internal memory error
running sql server 2008r2 standard SP3 - 8 GB memory max
One if our Applications is failing with this error: ERROR : (6784 | 6960) : (IS | INT_KOCPROD) : node01_KOCPROD : LM_36488 : Session task instance [s_DataSync_CNTCT_UPDT_MM2ING_STG_To_MQ] : [REP_12400 Repository Error (Microsoft SQL Server Native Client 11.0: There is insufficient system memory in resource pool 'internal' to run this query.SQL State: 42000 Native Error: 701State: 123 Severity: 17SQL Server Message: There is insufficient system memory in resource pool 'internal' to run this query.Database driver error...Function Name : ExecuteSQL Stmt : SELECT DISTINCT T.TASK_ID, T.SUBJECT_ID FROM OPB_TASK T, OPB_SESSION S, OPB_VALIDATE V, OPB_MAPPING M, OPB_WIDGET_INST I, OPB_SRC R, OPB_USER_GROUP U WHERE T.IS_VISIBLE = ? AND T.TASK_ID = S.SESSION_ID AND T.VERSION_NUMBER = S.VERSION_NUMBER AND T.TASK_ID IN (345) AND T.TASK_TYPE = 68 AND U.ID = ? AND U.TYPE = 1 AND S.MAPPING_ID = M.MAPPING_ID AND (M.IS_VISIBLE <> 2 OR (M.IS_VISIBLE = 2 AND M.CHECKOUT_USER_ID = U.ID)) AND I.MAPPING_ID = M.MAPPING_ID AND I.VERSION_NUMBER = M.VERSION_NUMBER AND I.WIDGET_TYPE = 1 AND R.SRC_ID = I.WIDGET_ID AND V.SUBJECT_ID = R.SUBJ_ID AND V.OBJECT_TYPE = I.WIDGET_TYPE AND V.OBJECT_ID = R.SRC_ID AND V.VERSION_NUMBER = R.VERSION_NUMBER AND V.INV_UTC > T.UTC_LAST_SAVED AND V.INV_TYPE = 1 AND T.IS_VALID = 1 AND (R.IS_VISIBLE <> 2 OR (R.IS_VISIBLE = 2 AND R.CHECKOUT_USER_ID = U.ID)) )]
In the sql server log we are getting the following error:
There is insufficient system memory in resource pool 'internal' to run this query.
Error: 701, Severity: 17, State: 123.
Full SQL server log attached. Can anyone help? kocsql01pdi.log
Microsoft SQL ServerMicrosoft SQL Server 2008
Last Comment
Vitor Montalvão
8/22/2022 - Mon
Megan Brooks
You had quite a few failures there, including two within replication subsystems. SPID 161 looks like it attempted a whole series of operations (unsuccessfully) without checking for errors after each one, or maybe it was checking but was coded to retry. It was still trying to go on in the last lines of the log segment.
There is a detailed trace for SPID 104 that doesn't mean a whole lot to me. The first failure logged was in SPID 182. Was that the actual beginning of the problem?
The query shown in the application error is lengthy, but it doesn't use JOIN syntax and that makes it look more complex than it really is. Nothing in it stands out to me that says it is the culprit; it seems more likely to be a victim.
Did anything change around the time this started happening?
Is there something that triggers the symptoms, and is the system OK the rest of the time? Does it recover the memory on its own?
Are all these SPIDs (other than perhaps the replication ones) spun off by one application operation, or are there multiple operations (and perhaps users) being affected?
Is CLR enabled and if so, is the application using it? Is the application using anything else "special" like extended stored procedures? Things that could run amok and use up all the memory?
Is this 64 bit SQL Server?
I am just trying to get some feeling for what might be going on.
Pawan Kumar
Is your query face this issue or even "SELECT TOP 100 * FROM a table" is also facing the same issue ?
Check sp_who2 and see which session is killing all memory
please let me know, Thnks
itsonlyme4
ASKER
Is there something that triggers the symptoms, and is the system OK the rest of the time? Does it recover the memory on its own? The Application running the lengthy query runs a series of jobs every 15 minutes to do a data sync operation. I agree that it is more likely a victim. The job does not fail every time it runs.. This is a 64 bit install of sql server . I am assuming CLR is OFF as it is off by default. We are configured for 8GB max memory but there is 40GB memory available on the Server. should I UP the memory max?
no update. we ended up recycling the instance yesterday and the problem corrected itself. Still not sure if adding more memory is the answer as I do not yet have root cause.
before we rebooted yesterday, we did see some processes with a very high "Resource Semiphore" LastWaitType
The processes died.. then we saw the Resource_Semaphore waits .. If this is a sign of memory pressure then I would think that increasing the MAX memory sounds like the way to go.
Vitor Montalvão
We are configured for 8GB max memory but there is 40GB memory available on the Server.
So what for you want those extra 40GB? A waste of money if you're not using it, right?
SQL Server as any other database management system (DBMS) is a resource eater, specially memory, even more than CPU, so everything that you can give to your SQL Server instance will only benefits the performance.
Vitor Montalvão
itsonlyme4, a feedback will be appreciated.
Cheers
There is a detailed trace for SPID 104 that doesn't mean a whole lot to me. The first failure logged was in SPID 182. Was that the actual beginning of the problem?
The query shown in the application error is lengthy, but it doesn't use JOIN syntax and that makes it look more complex than it really is. Nothing in it stands out to me that says it is the culprit; it seems more likely to be a victim.
Did anything change around the time this started happening?
Is there something that triggers the symptoms, and is the system OK the rest of the time? Does it recover the memory on its own?
Are all these SPIDs (other than perhaps the replication ones) spun off by one application operation, or are there multiple operations (and perhaps users) being affected?
Is CLR enabled and if so, is the application using it? Is the application using anything else "special" like extended stored procedures? Things that could run amok and use up all the memory?
Is this 64 bit SQL Server?
I am just trying to get some feeling for what might be going on.