Don't stop the world
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Horikawa, Takashi
To exploit the performance of contemporary hardware, it is crucial to resolve CPU scalability bottlenecks such as lock contention. The author has identified that some lock contention can be resolved at the cost of increasing memory usage and other lock contention can be mitigated by prepare-in-advance strategy. Among the lock contention that occurred in a benchmark execution, that caused by CLogControlLock is the former type and easily resolved; thanks to the increase in the main memory capacity. On the other hand, typical bottleneck categorized as the latter type is that caused by the critical section for extending a particular relation. Simple countermeasure that the author implemented was not effective for performance improvement as it caused a side effect. Some architectural change seems necessary for PostgreSQL in order to resolve the bottleneck. In this lecture, I will describe the outline and countermeasures of these bottlenecks, their effects, and necessary architectural change in PostgreSQL. Thanks to advances in device technology, it becomes possible to use abundant hardware resources such as many core CPUs and several hundreds Giga- or Tera-bytes of memory, which is an amount of computing resources that can not be imagined only a decade ago, and thus software development has to move towards utilizing such hardware resources. In spite of this situation, PostgreSQL that is a stable DBMS for, at least has an architecture suitable for non-rich hardware, which may cause a performance bottleneck in a DB server with contemporary hardware. In particular, scalability bottleneck, which has a large adverse effect when increasing the number of CPU cores, is a serious problem. Typical one is lock contention that becomes prominent when the number of processes trying to execute a critical section protected by the lock increases; when severe lock contention occurs, it's like stop-the-world as most of transaction processing stop waiting for the critical section becomes available..I have identified that some lock contention can be resolved at the cost of increasing memory usage and other lock contention can be mitigated by prepare-in-advance strategy. Among the lock contention that occurred in a benchmark execution, that caused by CLogControlLock is the former type and is easily resolved. The increase in the memory usage is acceptable for contemporary DB server which has a large amount of main memory. On the other hand, typical bottleneck categorized as the latter type is that caused by the critical section for extending a particular relation. Simple countermeasure that the author implemented was not effective for performance improvement as it caused a side effect. Some architectural change seems necessary for PostgreSQL in order to resolve the bottleneck. In this lecture, I will describe the outline and countermeasures of these bottlenecks, their effects, and necessary architectural change in PostgreSQL.
 So sorry for a moment. I start here. Now before my presentation, I say that I will upload this presentation material to PGCon website so please don't be busy with taking memo for details. And I have been engaged in performance evaluation study. At first, I was studying performance engineering including evaluation methodology and tools. Then my research shifted to how to identify and use of scalability bottlenecks. So my presentation material. And so my research shifted to how to identify and resolve scalability bottlenecks in many core systems. As an extension of this research, DBMS has been included in my research subject. Last year, I proposed a number of memory logging at PGCon 2016. Today's agenda is shown in this slide. The main topic is C-Lock, Control-Lock. Table extension issue is also included. So let's start with trend in computer architecture. This figure indicates the trend of processors. As you know, the single core performance is saturated. As the frequency is saturated. On the other hand, transistor count is increasing, which results in the increase in the number of cores. Therefore, we have to benefit from the multi-core CPUs. That is parallel processing. I would like to review the utilization of parallelism in DBMS quickly. Two types of parallelism are utilized. They differ in the granularity of parallelism. Transaction level parallelism has been utilized for a long time and is suitable for transactions that write in the database. The major point of enhancement for performance improvement is tuning of the bottleneck critical sections. On the other hand, operator-level parallelism is used for lead-only transactions. A typical example is the introduction of parallel query to PostgreSQL. I'm sorry, just wait a moment please. Before entering the main subject of this talk, I will review the critical section. At first, why critical section is necessary? This slide shows some behavior when two processors try to add one to the same shared variable. If critical section is not used, showing in the left, the result is sometimes correct but sometimes wrong. On the other hand, when critical section is used in a correct way, the result is always correct because the process 2 in this figure does not read the shared value until process 1 releases the look at the end of the critical section. The figure shown in the right illustrates such contention on the critical section. If contention occurs in the critical section, any processing does not progress resulting the performance degradation. As to servers with small number of cores, such contention is rare. Thus, the impact is small because most of the CPU time of every processor is utilized for meaningful processing. On the other hand, on servers with a large number of cores, the impact of critical section can be large as shown in this figure. This illustrates an extreme case where most of the CPU time is wasted waiting for the bottleneck critical section. This dotted line shows the waiting time. In other words, meaningful processing does not progress in this situation as if the clock has stopped. I call such behavior Stop the World operation here. To quantitatively estimate the impact of critical section to the performance, there is a famous equation by Amdahl. Where N is the number of cores and B is the ratio of processing times for critical section to the total processing time. It is ideal if B equals 0. Here is a quiz. Which is better? This figure shows the parallel and serial processing time for two cases. Case one is total processing time is shorter, but serial processing time is longer than those of case two. What do you think about these two cases? For simplicity, the system has only one critical section. The answer is that there is no universal answer. In the region where this x-axis is number of cores and y-axis shows the throughput. The region where number of cores is small, total processing time is the primary factor. Case one delivers better performance. On the other hand, when the number of cores is large, the primary factor shifted to serial processing time. So for the software that is expected to run on the server with large number of cores, it is necessary to reduce the serial processing time, even if the total processing time increases. This one is better when number of cores is large. Usually critical sections are implemented with using a lock mechanism. PostgreSQL uses lightweight lock. So I counted on the PostgreSQL website how many articles mention each lightweight lock. I gave the name of each lightweight lock to a search engine and checked the hit count. This table shows the result. Most popular ones are WAL related lightweight locks and serial control lock, which is the major topic of this talk. And then I will talk about serial control lock. Serial holds status information for each transaction, which is two bits to express one of in progress committed, strictly say committed and subcommitted and avoided. This information is used for data mining the visibility of the tuple as the value of the tuple becomes visible when the transaction that changes the value is committed. Of course, it is in the case of lead committed. As shown in this figure, transaction status is changed when processing of corresponding transaction finishes. As the PostgreSQL, every transaction is identified by the 32-bit integer value. Logically speaking, serial is a huge array with four gigahertz of two-bit status data. The current PostgreSQL deals with serial with a mechanism that is similar to page cache. As serial main body is stored in the storage and the necessary part of the processing is cached in the memory, the size of serial buffer is 8 kilobytes. As the serial buffers are managed with LRU replacement mechanism, the order in which buffers are placed in memory is random. The number of serial buffer buffers is a parameter that affects the performance. If the buffer count increases, the heat ratio increases, but the buffer search cost increases. Thus, they are trade-off. Historically, the serial buffer count gradually increased from 8 to 128, as shown in this table. PostgreSQL 9.6 uses 128 serial buffers as a comment in the source code saying, testing revealed that we can get the best performance by having 128 serial buffers. More than that, it doesn't improve performance. This article posted to the PostgreSQL hackers mailing list describing the role of serial control log. Serial control log is necessary to ensure mutual exclusion among operations for serial. These are writing the transaction status, checking transaction status, and serial page replacement, which occurs when the serial page is not found in serial buffers. This shows the basic idea of the serial management proposed in this talk. It is very simple. The evolution of serial page replacement. Since the number of transaction is finite, the memory for serial is also finite. The idea is that the status bits for all transactions are stored in the shared memory. This solution is possible if memory is abundant. In this case, both overheads can be eliminated. Serial page not found event does not occur because all status bits are on the memory. And linear search is no longer necessary because the memory location of a transaction directly corresponds to its transaction ID. I call this serial direct mapping from now. Even with this method, only page initialization remains necessary. In this method, is this method feasible or not? It's up to the memory size necessary for implementing the method. So let's estimate the memory size. Current length of transaction ID is 32 bits, which means that the maximum number of transactions is 4G. In practice, because of the transaction ID, TXID circulation problem, it is enough to take care of 2G transactions. As the status bits for transaction is 2, which is a quarter of a byte, the size of the status bit for 2G transaction is 512 megabytes. In addition, FOSL SQL maintains group LSN, which consumes another 512 megabytes for 2G transactions. Their total is 1 gigabyte, meaning that the memory cost is 1 gigabyte to implement the serial direct mapping mechanism. Here is the second question. Is 1 gigabyte of memory large enough to make the solution impossible? The answer depends on when the question is asked. This figure shows the trend of memory capacity. The original figure shows the trend until 2010. I extend the trend linearly. X axis is here. These tilted orange lines indicate the memory capacity. This tilted white belt shows the server's area. For example, about 10 years ago, memory size of ordinary servers was around 10 gigabytes. At that time, the answer for the question is yes. 1 gigabyte of memory was large. On the other hand, recent servers have 100 gigabytes or more memory. In this situation, the answer for the question is no. 1 gigabyte is less than 1% of memory. Just assigning 1 gigabyte of memory to C-LOG is feasible. In other words, Muwa saves Amdahl. I have built a prototype of C-LOG direct mapping based on possible SQL 9.6. As shown in this figure, the big remodeling is the change from SLRU, simple LRU to no LRU. This module provides APIs similar to SLRU. The remaining amount is shown on this slide. C-LOG.C and MEC file was modified to use no LRU. No LRU.C and no LRU.H was added to the source code tree. The source code of the prototype is published through JIT Hub. Whose address is shown here? I evaluated the performance implement produced by C-LOG direct mapping. The DB server used in the measurement was 96 cores and equipped with 1 terabytes of memory. Operating systems of the DB server and the client machine were relaxed and they were connected using 4 bit ethernet. The benchmark program used in the measurement was DBT2, which is open source implementation of C-PECC. And the version of the PostgreSQL was 9.6.2. Original PostgreSQL and its variation that the C-LOG direct mapping is installed are measured in the same condition. The results are shown in this slide. These graphs show the variation of the throughput as a function of the connection count. The graph on the left is a result of using unlogged table, which does not write WAL. And one of the right is result of using asynchronous commit. The implement is significant when unlogged table was used. On the other hand, when WAL was little, the implement was little. These results imply that as long as PostgreSQL executes C-PECC type transaction, the impact of the WAL overhead is large. And when WAL overhead is mitigated, C-LOG-related overhead becomes significant. There is an issue on how to implement the C-LOG direct mapping. The proper type always uses C-LOG direct mapping. As I mentioned, it is true that the impact of using 1 GB of memory for C-LOG becomes small. But there are systems that work with small memory. For small memory systems, it is necessary to be able to switch the C-LOG mechanism by specifying a parameter in the configuration file as shown in this figure. Next table extension issues. Next topic is another type of bottlenecks in which countermeasure differs from the previous one. Its concrete example is a log used in the table extension. The log is for ensuring only one worker process carries out table extension. This timing chart shows an example behavior when table extension occurs. At first, this worker process 1 came into a situation where free area in the table is not enough. Then it executes a procedure to expand the table with holding the corresponding log. In this situation, other processes that also need free space in the table have to wait until this table expansion procedure finishes. This case looks like log contentions. However, I think that the root cause of this contention is due to the strategy that table extension is carried out after free space is exhausted. As a countermeasure for this log contention, I have implemented a busy worker that periodically watches the specific table and points. Its free space becomes small. The PG background worker extends the table. I call this preparation in advanced strategy. By doing so, worker process gets less encounter with the free space shortage situation, which mitigates the log contention discussed here. Because the log will be acquired only by the busy worker. A prototype for this idea has been implemented and measured the degree of the performance improvement. The experimental setup was the same as that used in the evaluation of zero direct mapping. Obtained results shown in this graph indicate that performance was improved by this prepare in advanced strategy, but little. The improvement was not as expected. This is the reason why performance was not significantly improved. A possible assumption is that the busy worker is badly in harmony with the existing mechanism, more specifically auto vacuum. In spite of the lack of obvious evidence, it is quite dog vicious. Quality table speaking, the busy worker tries to keep the free space in the table. While auto vacuum tries to shrink the table when there is free space in the table. This figure illustrates these conflicting operations. The prepare in advanced strategy can also be applied elsewhere. One example is the process of assigning a new transaction ID. This figure shows that initialization of C log page, commit space and sub transaction page are carried out with acquiring the XID GenLog. Due to this structure, the execution time of the critical section enforced by the XID GenLog can be large, which contributes to increasing the contention. This section reveals some enhancement of post-release scale to improve many core performance. This graph illustrates the degree of the log contention occurred in post-release scale and was included in the 1914 report of Japanese post-release scale Enterprise Consortium. This report is in Japanese, sorry. The graph shows the number of log contention per transaction for each log, where benchmark program is PG bench. From this figure, the most conflicting log is that related to wall. The next one, C log control log and prok array log. Among them, worldwide log is not a true log conflict, so it is indicated by a dotted line. As enhancements for post-release scale so far, wall, cell and prok array have been the object of enhancement so far, as shown in this slide. Roughly speaking, the major source of the log contention in post-release scale are steel, wall, cell and prok array. For instance, I would like to show this graph included in the 1916 report of Japanese post-release scale Enterprise Consortium, which illustrates the effect of the countermeasure for the prok array log contention introduced in post-release scale 9.6. As can be seen in this figure, while throughput of post-release scale 9.5 saturates at a point in the number of clients, that post-release scale 9.6 increases without saturation. I would like to finish this talk with concluding remarks shown in this note. Exploiting params becomes more and more important due to the spread use of many core processors. It becomes feasible to place C log of all transactions in main memory. It contributes the decrease in the contention on C log control log resulting in CPU scalability improvement. Preparing advanced strategy is possible countermeasure for bottlenecks arising in extending relation, C log and commit TES sub-translucent page, etc. But it is necessary to adapt existing systems so that new mechanism can work efficiently. It is also necessary to study about its effect further. Thank you for listening. Any questions? My you give very high performance and on the north table it gives some critical performance. So I wanted to check with you, have you by any chance tried to do the work? Okay. Can I talk later? Okay.
 So sorry for a moment.  I start here.  Now before my presentation, I say that I will upload this presentation material to PGCon  website so please don't be busy with taking memo for details.  And I have been engaged in performance evaluation study.  At first, I was studying performance engineering including evaluation methodology and tools.  Then my research shifted to how to identify and use of scalability bottlenecks.  So my presentation material.  And so my research shifted to how to identify and resolve scalability bottlenecks in many  core systems.  As an extension of this research, DBMS has been included in my research subject.  Last year, I proposed a number of memory logging at PGCon 2016.  Today's agenda is shown in this slide.  The main topic is C-Lock, Control-Lock.  Table extension issue is also included.  So let's start with trend in computer architecture.  This figure indicates the trend of processors.  As you know, the single core performance is saturated.  As the frequency is saturated.  On the other hand, transistor count is increasing, which results in the increase in the number  of cores.  Therefore, we have to benefit from the multi-core CPUs.  That is parallel processing.  I would like to review the utilization of parallelism in DBMS quickly.  Two types of parallelism are utilized.  They differ in the granularity of parallelism.  Transaction level parallelism has been utilized for a long time and is suitable for transactions  that write in the database.  The major point of enhancement for performance improvement is tuning of the bottleneck critical  sections.  On the other hand, operator-level parallelism is used for lead-only transactions.  A typical example is the introduction of parallel query to PostgreSQL.  I'm sorry, just wait a moment please.  Before entering the main subject of this talk, I will review the critical section.  At first, why critical section is necessary?  This slide shows some behavior when two processors try to add one to the same shared variable.  If critical section is not used, showing in the left, the result is sometimes correct  but sometimes wrong.  On the other hand, when critical section is used in a correct way, the result is always  correct because the process 2 in this figure does not read the shared value until process  1 releases the look at the end of the critical section.  The figure shown in the right illustrates such contention on the critical section.  If contention occurs in the critical section, any processing does not progress resulting  the performance degradation.  As to servers with small number of cores, such contention is rare.  Thus, the impact is small because most of the CPU time of every processor is utilized  for meaningful processing.  On the other hand, on servers with a large number of cores, the impact of critical section  can be large as shown in this figure.  This illustrates an extreme case where most of the CPU time is wasted waiting for the bottleneck  critical section.  This dotted line shows the waiting time.  In other words, meaningful processing does not progress in this situation as if the clock  has stopped.  I call such behavior Stop the World operation here.  To quantitatively estimate the impact of critical section to the performance, there is a famous  equation by Amdahl.  Where N is the number of cores and B is the ratio of processing times for critical section  to the total processing time.  It is ideal if B equals 0.  Here is a quiz.  Which is better?  This figure shows the parallel and serial processing time for two cases.  Case one is total processing time is shorter, but serial processing time is longer than  those of case two.  What do you think about these two cases?  For simplicity, the system has only one critical section.  The answer is that there is no universal answer.  In the region where this x-axis is number of cores and y-axis shows the throughput.  The region where number of cores is small, total processing time is the primary factor.  Case one delivers better performance.  On the other hand, when the number of cores is large, the primary factor shifted to serial  processing time.  So for the software that is expected to run on the server with large number of cores,  it is necessary to reduce the serial processing time, even if the total processing time increases.  This one is better when number of cores is large.  Usually critical sections are implemented with using a lock mechanism.  PostgreSQL uses lightweight lock.  So I counted on the PostgreSQL website how many articles mention each lightweight lock.  I gave the name of each lightweight lock to a search engine and checked the hit count.  This table shows the result.  Most popular ones are WAL related lightweight locks and serial control lock, which is the major topic of  this talk.  And then I will talk about serial control lock.  Serial holds status information for each transaction, which is two bits to express  one of in progress committed, strictly say committed and subcommitted and avoided.  This information is used for data mining the visibility of the tuple as the value of the tuple  becomes visible when the transaction that changes the value is committed.  Of course, it is in the case of lead committed.  As shown in this figure, transaction status is changed when processing of corresponding  transaction finishes.  As the PostgreSQL, every transaction is identified by the 32-bit integer value.  Logically speaking, serial is a huge array with four gigahertz of two-bit status data.  The current PostgreSQL deals with serial with a mechanism that is similar to page cache.  As serial main body is stored in the storage and the necessary part of the processing is  cached in the memory, the size of serial buffer is 8 kilobytes.  As the serial buffers are managed with LRU replacement mechanism, the order in which  buffers are placed in memory is random.  The number of serial buffer buffers is a parameter that affects the performance.  If the buffer count increases, the heat ratio increases, but the buffer search cost increases.  Thus, they are trade-off. Historically, the serial buffer count gradually increased from  8 to 128, as shown in this table.  PostgreSQL 9.6 uses 128 serial buffers as a comment in the source code saying,  testing revealed that we can get the best performance by having 128 serial buffers.  More than that, it doesn't improve performance.  This article posted to the PostgreSQL hackers mailing list describing the role of serial control log.  Serial control log is necessary to ensure mutual exclusion among operations for serial.  These are writing the transaction status, checking transaction status, and serial page replacement,  which occurs when the serial page is not found in serial buffers.  This shows the basic idea of the serial management proposed in this talk.  It is very simple.  The evolution of serial page replacement.  Since the number of transaction is finite, the memory for serial is also finite.  The idea is that the status bits for all transactions are stored in the shared memory.  This solution is possible if memory is abundant.  In this case, both overheads can be eliminated.  Serial page not found event does not occur because all status bits are on the memory.  And linear search is no longer necessary because the memory location of a transaction directly corresponds to its transaction ID.  I call this serial direct mapping from now.  Even with this method, only page initialization remains necessary.  In this method, is this method feasible or not?  It's up to the memory size necessary for implementing the method.  So let's estimate the memory size.  Current length of transaction ID is 32 bits, which means that the maximum number of transactions is 4G.  In practice, because of the transaction ID, TXID circulation problem, it is enough to take care of 2G transactions.  As the status bits for transaction is 2, which is a quarter of a byte,  the size of the status bit for 2G transaction is 512 megabytes.  In addition, FOSL SQL maintains group LSN, which consumes another 512 megabytes for 2G transactions.  Their total is 1 gigabyte, meaning that the memory cost is 1 gigabyte to implement the serial direct mapping mechanism.  Here is the second question.  Is 1 gigabyte of memory large enough to make the solution impossible?  The answer depends on when the question is asked.  This figure shows the trend of memory capacity.  The original figure shows the trend until 2010.  I extend the trend linearly. X axis is here. These tilted orange lines indicate the memory capacity.  This tilted white belt shows the server's area.  For example, about 10 years ago, memory size of ordinary servers was around 10 gigabytes.  At that time, the answer for the question is yes.  1 gigabyte of memory was large.  On the other hand, recent servers have 100 gigabytes or more memory.  In this situation, the answer for the question is no.  1 gigabyte is less than 1% of memory. Just assigning 1 gigabyte of memory to C-LOG is feasible.  In other words, Muwa saves Amdahl.  I have built a prototype of C-LOG direct mapping based on possible SQL 9.6.  As shown in this figure, the big remodeling is the change from SLRU, simple LRU to no LRU.  This module provides APIs similar to SLRU.  The remaining amount is shown on this slide.  C-LOG.C and MEC file was modified to use no LRU.  No LRU.C and no LRU.H was added to the source code tree.  The source code of the prototype is published through JIT Hub.  Whose address is shown here?  I evaluated the performance implement produced by C-LOG direct mapping.  The DB server used in the measurement was 96 cores and equipped with 1 terabytes of memory.  Operating systems of the DB server and the client machine were relaxed and they were connected using 4 bit ethernet.  The benchmark program used in the measurement was DBT2, which is open source implementation of C-PECC.  And the version of the PostgreSQL was 9.6.2.  Original PostgreSQL and its variation that the C-LOG direct mapping is installed are measured in the same condition.  The results are shown in this slide.  These graphs show the variation of the throughput as a function of the connection count.  The graph on the left is a result of using unlogged table, which does not write WAL.  And one of the right is result of using asynchronous commit.  The implement is significant when unlogged table was used.  On the other hand, when WAL was little, the implement was little.  These results imply that as long as PostgreSQL executes C-PECC type transaction, the impact of the WAL overhead is large.  And when WAL overhead is mitigated, C-LOG-related overhead becomes significant.  There is an issue on how to implement the C-LOG direct mapping.  The proper type always uses C-LOG direct mapping.  As I mentioned, it is true that the impact of using 1 GB of memory for C-LOG becomes small.  But there are systems that work with small memory.  For small memory systems, it is necessary to be able to switch the C-LOG mechanism by specifying a parameter in the configuration file as shown in this figure.  Next table extension issues.  Next topic is another type of bottlenecks in which countermeasure differs from the previous one.  Its concrete example is a log used in the table extension.  The log is for ensuring only one worker process carries out table extension.  This timing chart shows an example behavior when table extension occurs.  At first, this worker process 1 came into a situation where free area in the table is not enough.  Then it executes a procedure to expand the table with holding the corresponding log.  In this situation, other processes that also need free space in the table have to wait until this table expansion procedure finishes.  This case looks like log contentions.  However, I think that the root cause of this contention is due to the strategy that table extension is carried out after free space is exhausted.  As a countermeasure for this log contention, I have implemented a busy worker that periodically watches the specific table and points.  Its free space becomes small.  The PG background worker extends the table.  I call this preparation in advanced strategy.  By doing so, worker process gets less encounter with the free space shortage situation, which mitigates the log contention discussed here.  Because the log will be acquired only by the busy worker.  A prototype for this idea has been implemented and measured the degree of the performance improvement.  The experimental setup was the same as that used in the evaluation of zero direct mapping.  Obtained results shown in this graph indicate that performance was improved by this prepare in advanced strategy, but little.  The improvement was not as expected.  This is the reason why performance was not significantly improved.  A possible assumption is that the busy worker is badly in harmony with the existing mechanism, more specifically auto vacuum.  In spite of the lack of obvious evidence, it is quite dog vicious.  Quality table speaking, the busy worker tries to keep the free space in the table.  While auto vacuum tries to shrink the table when there is free space in the table.  This figure illustrates these conflicting operations.  The prepare in advanced strategy can also be applied elsewhere.  One example is the process of assigning a new transaction ID.  This figure shows that initialization of C log page, commit space and sub transaction page are carried out with acquiring the XID GenLog.  Due to this structure, the execution time of the critical section enforced by the XID GenLog can be large,  which contributes to increasing the contention.  This section reveals some enhancement of post-release scale to improve many core performance.  This graph illustrates the degree of the log contention occurred in post-release scale and was included in the 1914 report of Japanese post-release scale Enterprise Consortium.  This report is in Japanese, sorry.  The graph shows the number of log contention per transaction for each log, where benchmark program is PG bench.  From this figure, the most conflicting log is that related to wall.  The next one, C log control log and prok array log.  Among them, worldwide log is not a true log conflict, so it is indicated by a dotted line.  As enhancements for post-release scale so far, wall, cell and prok array have been the object of enhancement so far, as shown in this slide.  Roughly speaking, the major source of the log contention in post-release scale are steel, wall, cell and prok array.  For instance, I would like to show this graph included in the 1916 report of Japanese post-release scale Enterprise Consortium,  which illustrates the effect of the countermeasure for the prok array log contention introduced in post-release scale 9.6.  As can be seen in this figure, while throughput of post-release scale 9.5 saturates  at a point in the number of clients, that post-release scale 9.6 increases without saturation.  I would like to finish this talk with concluding remarks shown in this note.  Exploiting params becomes more and more important due to the spread use of many core processors.  It becomes feasible to place C log of all transactions in main memory.  It contributes the decrease in the contention on C log control log resulting in CPU scalability improvement.  Preparing advanced strategy is possible countermeasure for bottlenecks arising in extending relation, C log and commit TES sub-translucent page, etc.  But it is necessary to adapt existing systems so that new mechanism can work efficiently.  It is also necessary to study about its effect further.  Thank you for listening. Any questions?  My  you give very high performance and on the north table it gives some critical performance.  So I wanted to check with you, have you by any chance tried to do the work?  Okay. Can I talk later?  Okay.
Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_0_131.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_132_311.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_312_1763.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_1764_3227.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_3228_4607.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_4608_6527.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_6528_8699.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_8700_8747.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_8748_10367.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_10368_11783.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_11784_14471.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_14472_23435.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_23436_23567.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_23568_24131.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_24132_24275.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_24276_24371.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_24372_25955.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_25956_31475.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_31476_36731.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_36732_38063.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_38064_38111.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_38112_41663.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_41664_43379.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_43380_46979.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_46980_47027.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47028_47123.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47124_47195.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47196_47243.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47244_47399.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47400_47603.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47604_47807.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_47808_48023.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48024_48119.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48120_48203.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48204_48335.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48336_48503.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48504_48587.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48588_48635.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48636_48707.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48708_48767.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48768_48839.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48840_48887.png Takashi_Horikawa__Don_t_stop_the_world_-_PGCon_201_pCeBxT0L_aU_48888_48905.png