{"id":686,"date":"2020-03-01T14:38:45","date_gmt":"2020-03-01T17:38:45","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=686"},"modified":"2020-07-19T19:11:44","modified_gmt":"2020-07-19T22:11:44","slug":"exadata-x8m-workshop","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/exadata-x8m-workshop\/","title":{"rendered":"Exadata X8M, Workshop"},"content":{"rendered":"

When Exadata X8M was released during the last Open World I made one post about the technical details about it. You can check it here: Exadata X8M<\/a> (this post received some good shares and reviews<\/a>). If you read it, you can see that I focused in more internal details (like torn blocks, one side path, two sides read\/writes, and others), that differ from the normal analyses for Exadata X8M.<\/p>\n

But recently I was invited by Oracle to participate exclusive workshop about Exadata X8M and I needed to share some details that picked me up. The workshop was done directly from Oracle Solution Center in Santa Clara Campus (it is an amazing place that I had an opportunity to visit in 2015, and have a rich history \u2013 if you have the opportunity, visit), and cover some technical details and with the hands-on part.<\/p>\n

Unfortunately, I can\u2019t share everything (I even don\u2019t know if I can share something), but see the info below.<\/p>\n

<\/p>\n

Exadata X8M<\/h2>\n

Little briefing before. If you don\u2019t know, the big change for Exadata X8M was the add of RDMA memory directly at the storage server. Basically, added Intel Optane Memory (that it is nonvolatile by the way), in front of everything (including flashcache). Called PMEM (Persistent memory) as Exadata.<\/p>\n

\"\"<\/a><\/p>\n

You can see more detail about Exadata at \u201cExadata Technical Deep Dive: Architecture and Internals<\/a>\u201d available at Oracle Web Site.<\/p>\n

And just to add, the database server can access directly it, without passing operational system caches in the middle since the RDMA is ZDP (Zero-loss Zero-Copy Datagram Protocol<\/a>). The data goes directly from database server memory to storage server memory. And if you think that now it uses RCoE (100GB\/s network), it is fast.<\/p>\n

Workshop<\/h2>\n

As told the workshop was more than a simple marketing presentation and had hands-on part. The focus was to show the PMEM gains over a \u201ctraditional\u201d Exadata. Gains over log writes (PMEMLog) and gains over cache for reads (PMEMCache).<\/strong><\/p>\n

The test executed some loads (to test the log writes) and reads (to test the cache) for some defined period. Two runs were made, one with features disabled and other with enabled.  And after that, we can compare the results.<\/p>\n

Just to be clear that the focus of the tests was not to stress the machine and force to reach the limits. The focus was to see the difference between executions with and without PMEMCache and PMEMLog enabled. So, the numbers that you see here are below the limits for the Exadata.<\/p>\n

Environment<\/h3>\n

Just to be more precise, the Workshop runs over Exadata X8M Extreme Flash Edition. This means that the disk was the flash driver. So, here we are comparing Flash against Memory. You will see the numbers below, but when read it remember that is flash, and think that they will be even slower in \u201cnormal\u201d environment with disks instead of flash. Check the datasheet<\/a> for more info.<\/p>\n

For PMEM, the Exadata had 1.5TB of Intel Optane Memory. Twelve modules attached in each storage:<\/p>\n

\"\"<\/a><\/p>\n

PMEMLog<\/h3>\n

The PMEMlog works in the same way that flashlog. It will speed up the redo writes that came from LGWR. For the workshop was first executed one run without PMEMLog, and the numbers were:<\/p>\n