Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 235

Memory considerations for CDBs
You have seen in Chapter 3 that x86-64 servers are able to take more and more memory and make good use of it. Even
a modest dual-socket E5-2600-v2 series Xeon system could potentially address 1.5 TB of memory depending on server
model. Memory is readily available most of the time, and in consolidated servers memory should not be scarce: that
would be saving at the wrong end.
With that being said, as with any consolidation platform you can expect a lot of consolidated systems—PDBS or
otherwise—to be very memory hungry. Interestingly there is no measurable overhead when opening a mounted PDB,
however a large number of processes will obviously be a strain on the number of connections the system can serve.
To measure the impact of sessions connecting to the Oracle server, a little experiment has been conducted. Consider
the PDB “swingbench1”, which has extensively been used to benchmark the system performance. How much overhead
does a new connection add to the operating system without large pages enabled? A small 8GB SGA will already suffer
a huge overhead from a larger number of sessions doing very little actual work when large pages are not configured.
Consider the following example of an idle system. With the database started, the PageTables entry in the / proc/meminfo
file for Oracle Linux 6.4 will show about 46MB used:
[oracle@server1 ~]$ grep -i paget /proc/meminfo
PageTables: 46380 kB
Using a little script to generate some XML on the fly will be used as benchmark.
[oracle@server1 ~]$ cat xml.sql
declare
a xmltype;
begin
a := xmltype('<a>toto</a>');
dbms_lock.sleep(20);
end;
/
exit;
The test consists of 700 different executions of the same script in the current shell:
[oracle@server1 ~]$ for i in $(seq 1 700) ; do
> sqlplus /@swingbench1 @xml &
> done
Not ■ this example uses the secure external password store to connect to a tNs alias without having to provide a
password. You can read more about that connectivity method in Chapter 10.
How much overhead does this generate? A lot! Periodically checking the PageTables entries from my system
showed that with all 700 sessions connected, the kernel allocated around 750 MB:
[oracle@server1 ~]$ grep -i paget /proc/meminfo
PageTables: 750680kB