inmemory: sa00 process
Posted by Riyaj Shamsudeen on September 11, 2014
After the restart of a 12c inmemory database with 300GB+ SGA, I noticed that an Oracle background process sa00 was consuming a bit of CPU. Documentation suggests that it is SGA Allocator process, however, ipcs -ma command shows that the shared memory segment is already allocated. I was curious, of course, what would that background process will be allocating?.
Process stack of the process shows that it is touching SGA pages to pre-page SGA memory pages.
$ pstack 21131 #0 0x0000000000d9996e in ksmprepage_memory () #1 0x0000000000d99369 in ksm_prepage_sga_seg () #2 0x0000000003a5c78b in skgmapply () #3 0x0000000000da686a in ksmapply_v2 () #4 0x0000000000d9a82c in ksmprepage () #5 0x0000000000d99f89 in ksm_sslv_exec_cbk () #6 0x0000000000f79810 in ksvrdp () #7 0x00000000031013b7 in opirip () #8 0x0000000001bb0a08 in opidrv () #9 0x00000000026c0f71 in sou2o () #10 0x0000000000bbd85e in opimai_real () #11 0x00000000026cb6bc in ssthrdmain () #12 0x0000000000bbd72c in main () $ ps -ef|grep 21131 oracle 21131 1 96 15:00 ? 00:01:50 ora_sa00_XXXXXX
Two notable changes in this area:
1. Incidentally, pre_page_sga initialization parameter was defaulted to a value of FALSE until 11.2. In version 12.1, the parameter value defaults to TRUE.
2. As huge SGA is expected for inmemory databases, a new background process SA00 is also created to touch all SGA memory pages at startup.
As inmemory worker processes will be populating the inmemory column store soon after the startup, touching memory pages at instance startup makes sense, and the feature should improve the performance of inmemory population. At least, Worker processes doesn’t need to suffer from huge amount page faults. (note that this SGA is not using hugepages).
Change to the parameter pre_page_sga also should improve the performance of inmemory scan, as the memory map entries will be setup at the process startup. However, I am not quite clear, how this change will affect the performance of a connection storm, i.e. if there are numerous database connections in a short period of time and disconnects. Isn’t that the reason why the pre_page_sga was defaulted to FALSE? But, I need to test this thoroughly to understand the implications further.