db error caused by dbcc memusage

[Former Member]

issue dbcc memusage and system is frozen, then got following error

00:00000:00000:2014/10/16 09:50:23.91 kernel  secleanup: time to live expired on engine 1

00:00000:00009:2014/10/16 09:50:23.93 kernel  Terminating the listener with protocol tcp, host myserver, port 4101 because the listener execution context is located on engine 1, which is not responding.

00:00000:00009:2014/10/16 09:50:23.93 kernel  ************************************

00:00000:00009:2014/10/16 09:50:23.93 kernel  curdb = 1 tempdb = 2 pstat = 0x200

00:00000:00009:2014/10/16 09:50:23.93 kernel  lasterror = 0 preverror = 0 transtate = 1

00:00000:00009:2014/10/16 09:50:23.93 kernel  curcmd = 0 program =

00:00000:00009:2014/10/16 09:50:23.93 kernel  pc: 0x0000000000cd0847 upsleepgeneric+0x437()

00:00000:00009:2014/10/16 09:50:23.93 kernel  pc: 0x0000000000cadcae listener_checkagain+0x1be()

00:00000:00009:2014/10/16 09:50:23.93 kernel  pc: 0x0000000000cad938 listener+0x338()

00:00000:00009:2014/10/16 09:50:23.93 kernel  pc: 0x0000000000cce388 kpstartproc+0x48()

00:00000:00009:2014/10/16 09:50:23.93 kernel  end of stack trace, spid 10, kpid 1638425, suid 0

00:00000:00009:2014/10/16 09:50:23.93 kernel  Started a new listener task with protocol tcp, host myserver, port 4101.

then system repair itself within 1-2 minutes.

dbcc memusage is fine on another staging server.

what's the possible reason for this? hardware?

[jayrijnbergen · Accepted solution]

dbcc memusage can cause problems on multi engine servers

how many engines do you have configured?

check: exec sp_configure "number of engines"

and which ASE version are you running?

[Former Member · Accepted solution]

2 engine for ASE 12.5.4

As it's for production. So I am afraid of doing it again. How to figure it the reason and resolve it?

[jayrijnbergen · Accepted solution]

no solution, known issue

On 12.5.4 don't run it on production on a multi-engine server

Probably you have a good reason to be on 12.5.4, but maybe it's time to upgrade?

And why do you actually need to run it in production?

[Former Member · Accepted solution]

I want to know the the usage of memory in detail for performance reason.

[jayrijnbergen · Accepted solution]

You can get the memory information from standard procedures:

sp_configure memory

sp_configure "procedure cache"

sp_cacheconfig

this is all mostly static config, no need to check with dbcc memusage

if you want info for performance tuning, much better to

- install MDA tables (and a tool like Asemon or other similar tool to visualize MDA data)

- use sp_sysmon (if using MDA is not an option)

[Former Member · Accepted solution]

Thanks. What's the reason for this case? Will it impact the system running? will it crash system someday?

[jayrijnbergen · Accepted solution]

The problem you had was caused by dbcc memusage. So don't run it.

if you don't want to install MDA tables, use sp_sysmon

e.g. to get performance counters for 10 minutes: exec sp_sysmon "00:10:00"

memory allocation itself doesn't say much about performance.

If you just want to know how much memory is allocated, than check on OS level.

(e.g. on Unix/Linux with: ipcs -ma)