Quantcast
Channel: SCN : Unanswered Discussions - SAP HANA and In-Memory Computing
Viewing all articles
Browse latest Browse all 4343

SIGSEGV Signal 11 Crashdumps TimerThread after "unused_retention_period" enabled (Note 2127458)

$
0
0

Greetings all,

 

We are just surviving on a now-undersized BW7.3 SP8 on HDB rev83 (6 node scaleout).  While we are waiting on new hardware over next few months, we are exploring ways to better keep our heads above water for longer.  One of these option is enabling HANA to unload columns that are not used for some time (e.g. non-reporting data in a typical LSA propagation layer) to avoid main memory contention during the day while users run their reports.  We are mindful this is not the SAP recommended approach, and are only exploring this option as a workaround.

 

2127458 - FAQ: SAP HANA Loads and Unloads

This note indicated a way to enable the column displacement from memory after a specified retention period.

 

 

When testing with this enabled 'System'-wide across all hosts, we found that the master node was crashdumping and rte-dumping frequently.

Here is a sample trace files generated:

indexserver_saphdp-an1.30003.crashdump.20150427-155006.060789.trc

indexserver.perspage.20150427-134110000.0x00000000002ad1e8L.0x0000c00000120000P.1.ok.dmp

indexserver_saphdp-an1.30003.rtedump.20150427-134037.060789.page.trc

indexserver.perspage.20150427-134042000.0x00000000002ad1e8L.0x0000c00000120000P.0.corrupt.dmp

indexserver_saphdp-an1.30003.crashdump.20150427-132538.058793.trc

indexserver.perspage.20150427-132101000.0x00000000002ad1e8L.0x0000c00000120000P.9.corrupt.dmp

indexserver_saphdp-an1.30003.rtedump.20150427-132032.058793.page.trc

indexserver.perspage.20150427-132033000.0x00000000002ad1e8L.0x0000c00000120000P.0.corrupt.dmp

 

So we test with this enabled just across the SLAVE hosts, we found that they were crashdumping occasionally.

Here is a sample trace files generated:

indexserver_saphdp-an4.30003.crashdump.20150505-064045.050854.trc

indexserver_saphdp-an3.30003.crashdump.20150503-152138.003832.trc

indexserver_saphdp-an4.30003.crashdump.20150503-131004.037534.trc

indexserver_saphdp-an5.30003.crashdump.20150503-074249.029552.trc

indexserver_saphdp-an3.30003.crashdump.20150503-021555.040263.trc

indexserver_saphdp-an5.30003.crashdump.20150502-182801.028108.trc

 

In the crashdump trace files, we notice it is always a Signal 11 on the TimerThread of the particular indexserver that crashed.  Here is a summary (bold highlighted words are found in every crashdump trace file:

 

"[CRASH_SHORTINFO]  exception short info: (2015-05-05 06:40:45 366 Local)

SIGNAL 11 (SIGSEGV) caught, thread: 4302[thr=nnnnn]: TimerThread, etc..."

 

Also, if it's any help, the error code 1 is detected for Signal 11:

"[CRASH_EXTINFO]  extended exception info: (2015-05-05 06:40:45 367 Local)

----> Dump of siginfo contents <----

  signal:      11(SIGSEGV)

  code:        1(SEGV_MAPERR: address not mapped to object)"

 

 

We have logged a SAP message and going through the motions of opening system access, upload tracefiles etc.

 

Just wanted to check with the community here whether you have encountered and/or resolved similar crashdump issues for Rev83?

 

Thanks.


Viewing all articles
Browse latest Browse all 4343

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>