ScaleArc Performance Benchmarking with sysbench
|
|
- Rachel Nash
- 6 years ago
- Views:
Transcription
1 MySQL Performance Blog ScaleArc Performance Benchmarking with sysbench Peter Boros, 2014
2 1/31 Author: Peter Boros Revision: 2.0 Date: Mar 28, 2014 Customer: ScaleArc Contents 1 Executive Summary 3 2 About ScaleArc for MySQL 5 3 Benchmarking setup Client machines Database machines MySQL configuration ScaleArc software appliances Network 7 4 Measurements TTL-based caching Read-only Sysbench throughput Sysbench response time CPU utilization Effects of caching on read-only workload Sysbench throughput Sysbench response time CPU utilization Read-write Sysbench throughput Sysbench response time CPU utilization Effects of caching on read-write workload Sysbench throughput Sysbench response time CPU utilization 30
3 2/31 5 Conclusion 31
4 1 Executive Summary 3/31 1 Executive Summary ScaleArc hired Percona to perform various test on its database traffic management product. This document is the outcome of the benchmarks carried out by Uday Sawant (ScaleArc) and Peter Boros (Percona). The goal of these benchmarks is to identify the potential overhead of the ScaleArc software itself and the potential benefits of caching. The benchmarks were carried out with the trunk version of sysbench. For this reason, we used a very small set of data, so the measurements will be fast, and it's known that caching has huge benefits when the queries themselves are rather expensive. We decided that we would rather show that benefit with a real-world application, which is coming later is this series. In this summary graph it's visible that in terms of throughput (read-only benchmark, which is relevant for read mostly applications), ScaleArc doesn't have any significant overhead, while caching can have potentially huge benefits.
5 1 Executive Summary 4/31 The situation is pretty similar with response times. ScaleArc doesn't add any significant overhead, and caching can mean huge benefit in terms of response time as well. In case of this particular workload (which is read only sysbench), using caching means a roughly 3x increase in throughput and a roughly 80% drop in response time. Overall, ScaleArc is a good product in terms of performance and features as well. I would definitely recommend it.
6 2 About ScaleArc for MySQL 5/31 2 About ScaleArc for MySQL ScaleArc for MySQL is a software appliance that drops in transparently between applications and databases to improve application availability and performance. It requires no changes to applications or databases and delivers: Instant scale up - transparent connection pooling and multiplexing, TTL-based transparent caching, surge protection Transparent scale out - read/write split, load balancing, query routing, sharding Automatic high availability - automatic failover Real-time actionable analytics 3 Benchmarking setup 3.1 Client machines The client machines are running the benchmarking software like sysbench in case of these benchmarks. CPU: 2 x Intel(R) Xeon(R) CPU E GHz (6 cores, chip multithreading off) Memory: 64G We used 2 clients. The results of the 2 clients are graphed separately, so it's visible that they put the same amount of workload on the database or ScaleArc software. 3.2 Database machines CPU: 2 x Intel(R) Xeon(R) CPU E GHz (6 cores, chip multithreading off) Memory: 64G Running MySQL Community Edition
7 2 About ScaleArc for MySQL 6/ MySQL configuration [mysqld] max_allowed_packet = 64M thread_cache = 256 query_cache_size = 0 query_cache_type = 0 max_connections = max_user_connections = max_connect_errors = wait_timeout = interactive_timeout = log-error=/var/lib/mysql/mysql.err back_log=60000 innodb_buffer_pool_size = 3G innodb_additional_mem_pool_size = 16M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 0 innodb_flush_method = O_DIRECT innodb_open_files = 2000 innodb_file_per_table innodb_log_file_size=2g innodb_log_files_in_group=2 innodb_purge_threads=1 innodb_max_purge_lag=0 innodb_support_xa=0 innodb_locks_unsafe_for_binlog = 1 innodb_buffer_pool_instances=8 sql_mode=no_engine_substitution,strict_trans_tables The buffer pool of the database is intentionally small, so it's easy to generate a disk-bound workload. Please note that the following settings are not recommended in production. innodb_support_xa=0 innodb_locks_unsafe_for_binlog = 1 We used these settings to drive the node to its peak performance, avoiding any possible overhead which might be required on a production system. In typical production settings, these are not set, and binary logging is enabled, which potentially reduces ScaleArc's overhead further.
8 3.3 ScaleArc software appliances 7/ ScaleArc software appliances CPU: 2 x Intel(R) Xeon(R) CPU E GHz (6 cores, chip multithreading off) Memory: 64G The machines were running ScaleArc for MySQL Network The machines were connected using 10G connections.
9 4 Measurements 8/31 4 Measurements All of the measurements were done with a very small database that completely fits in memory. --oltp-table-size= oltp-tables-count=64 In these benchmarks, we expected both the database and ScaleArc to be CPU bound. In case of a disk-bound workload, ScaleArc would shine even more than in this benchmark. If the queries are more expensive (they have to hit storage), the overhead in % is smaller, and in case of caching the query-by-query benefit is bigger. We measured 3 different setups, both on read-only and read-write cases. These are the following. Direct connection to the database. Connection to the database through ScaleArc, where ScaleArc only acts as a pass-through filter (since it's a load balancer that speaks the MySQL wire protocol, all the mechanics for that are still in place). Please note that this setup doesn't make sense in real life. The purpose of this setup is to show the potential overhead of using ScaleArc and uncovering potential limitations of the ScaleArc software itself. In a more realistic case in this configuration ScaleArc would load balance between multiple servers. Connection to database through ScaleArc, where ScaleArc is allowed to cache. Caching in ScaleArc is TTL (Time To Live)-based caching, meaning that a read query's results are cached in ScaleArc. If that read query is seen again before expiring, the query is not run again on the database server but rather served from the cache. Once the timer for the cached query expires, the query will be issued on the database again. Caching of course only works for reads, which are not in an explicit transaction (autocommit is on and no START TRANSACTION is issued). Because of that, we used --oltp-skip-trx during cached benchmarks (read-only case). In case of these benchmarks, the TTL was 1 hour, because we wanted to saturate the ScaleArc software while serving cached queries. An 1 hour TTL might be unrealistic for some applications, while for other applications even an 1 day TTL is something they can live with for some queries. TTL can be as low as 1 second and as high as 199 days. In this case, we wanted to measure the cache's performance, so we wanted the queries to be cached during the entire benchmark run to show the potential gain even in case of very small queries. 4.1 TTL-based caching It's important to note that the cache's expiration is controlled by a TTL value - there is no other invalidation, so it's possible to read stale data when the query results is changed, but the cache is not expired. Reading stale data alone is ok for most applications, it can happen with a regular, asynchronous slave if it's lagging behind the master (and it always lagging behind somewhat). Otherwise, the cache is pretty similar to MySQL's query cache, which doesn't suffer from the stale read problem, but it has a coarse invalidation (if a table is written, the cache entries belonging to the given table are flushed). While the cache is flushed, the query cache mutex is held, which blocks reads even. Because of the mutex, the built-in query cache is a very usual performance bottleneck. ScaleArc's cache doesn't suffer from this. It's important to note that ScaleArc caches nothing by default. Also, there are other ways to invlidate cache entries apart from waiting for the TTL to expire.
10 4 Measurements 9/31 API Call based invalidation (you can clear the cache for an entire query pattern rule with one API call) Query comment based invalidation (you can put a comment /wipe/ before a query and wipe and refresh the cache) Cache Bypass (you can send a comment /nocache/ and bypass the cache for that specific query)
11 4.2 Read-only 10/ Read-only Sysbench throughput In the lower region of threads (up to 32), we see that the TPS value significantly drops in case of going through ScaleArc. That's nothing to be surprised about, the reason for that is network roundtrips. Because ScaleArc is a software appliance, it adds a hop between the database and the application, which introduces latency. If the number of threads is higher (32 and up), this starts to matter less and less, and performance is almost identical which is very impressive. It means that around the optimal degree of parallelism for these machines, ScaleArc introduces very little (barely measurable) overhead.
12 4.2 Read-only 11/ Sysbench response time This graph contains the response times belonging to the previous benchmarks. This is really hard to read because at 4096 threads, the system is overloaded, and the response time is much more than in the maximum throughput region. Because it's multiple orders of magnitude higher, the interesting response times are not readable from this graph.
13 4.2 Read-only 12/31 The following graph is the same as above, except that the y axis is limited to 250 ms, so the region which is not visible on the graph above is visible here. What we see there regarding the overhead is pretty much the same as we saw in case of the throughput graph, which means that ScaleArc by itself introduces immeasurably low latency (which explains the difference in cases when parallelism is low). Usually applications which are utilizing the database server are using significantly more than one thread (in MySQL a single query always uses a single thread, in other words there is no intra-query parallelism). The latency from 32 threads above is actually somewhat lower when going through ScaleArc (the exact tipping point can be different here based on the number of CPUs). The reason for that is ScaleArc itself uses an event loop to connect to MySQL, so at a high concurrency, and can schedule sending the traffic to MySQL differently. This only matters when otherwise the MySQL server is saturated CPU-wise.
14 4.2 Read-only 13/ CPU utilization Last but not least, this graph contains the CPU utilization of the different setups. The left-hand side shows the CPU utilization when connecting directly to the database, and the right-hand side shows connecting through ScaleArc. In both cases, the database server's CPU is the bottleneck. It's visible that the client node's CPU is more than 75% idle (only client1 is graphed to improve readability, client2 is practically the same). From 32 threads and up, the blue bar (CPU user%) is relatively high on the database servers, as is the green (CPU sys%). From 64 threads, the idle time is practically 0, until the systems are overloaded. On the right hand side, we can see that ScaleArc at this load still had 50% idle CPU, which means that we could practically do the same benchmark on another set of boxes through the very same ScaleArc, and only then it will be fully utilized. We are talking about 3000 sysbench tps here. One more interesting thing to note is the relatively high system time of ibd. This is also because of the way ScaleArc connects to the database (see the previous paragraph).
15 4.2 Read-only 14/31 [ 17s] threads: 64, tps: , reads/s: , writes/s: 0.00, response time: 35.22ms (95%) These threads are from a single client, which means that ScaleArc could keep up with parsing roughly statements / second with utilizing half of its CPU, which is impressive. Please note that the ScaleArc software in this case was tuned towards this type of workload, which means we had more query processing threads. In case of caching, we will have more cache handler threads.
16 4.3 Effects of caching on read-only workload 15/ Effects of caching on read-only workload Sysbench throughput The next set of graphs will compare the cases when cache is used and not used. The preceding TPS graph contains reads / second (because we measured with --oltp-skip-trx), so roughly reads corresponds to roughly 3000 transactions in the earlier setup (14 reads in a transaction). On the left-hand side of the graph, the cached throughput is visible with green - on the right-hand side, the non-cached throughput is visible with red (direct access) and blue (access through ScaleArc as a pass-through filter). It's visible that caching improves the speed drastically, but when ScaleArc becomes overloaded (8192 client threads, 4096 from each client), the performance becomes somewhat
17 4.3 Effects of caching on read-only workload 16/31 inconsistent, which is understandable considering how few cores ScaleArc was running on. On the graph, the dots are translucent, which means the colors are brighter in the areas that have more samples. Even in the overloaded case, the majority of the samples are in the region of 100k+ reads / second across two clients, which means that the performance degrades very gracefully even under heavy load.
18 4.3 Effects of caching on read-only workload 17/ Sysbench response time Like in the case of a non-cached workload, the response times are not too readable because of the very high response times when the systems are overloaded. But from the overloaded response times visible, it seems like using caching doesn't make response times worse.
19 4.3 Effects of caching on read-only workload 18/31
20 4.3 Effects of caching on read-only workload 19/31 Like in the case of non-cached workload, this graph is the zoomed version of the previous one. Here the maximum of the y axis is 100 ms. From this graph, it's visible that at lower concurrency and at the optimal throughput, caching actually helps response time. This is understandable, since in case of a cache hit, ScaleArc can serve the results, and the client (in our case here sysbench) doesn't have to go to the database, so a roundtrip and database processing time is spared. It's also worth mentioning that the data "comes from memory," it doesn't matter if we hit the ScaleArc cache of the database. When the ScaleArc cache is used, the response time is lower because the additional roundtrip to the database and potential database work (like parsing SQL) is avoided. This means that caching can have benefits even if the database fits in the buffer pool. The improvement is always subject to the workload - caching helps the most when it can cache relatively expensive queries like aggregations and queries hitting the storage.
21 4.3 Effects of caching on read-only workload 20/ CPU utilization Similarly to the previous case, the preceding graph shows CPU utilization of the various components. In case of the cached workload, the client itself is much more utilized (since it gets responses sooner, it has to generate the traffic faster). With this kind of workload, when using only one client, we would hit the client's CPU as the performance bottleneck. The database is interesting too. With caching, its CPU is barely used. This is because if a query is served from the cache, it never gets to the database, so the database's CPU utilization will be lower. In other words, using the cache helps to offload the database. If offloading is visible on ScaleArc's graphs, when caching is used, the CPU on the server hosting ScaleArc is much more utilized. For this benchmark, the ScaleArc software was tuned to handle a cached workload, which means more cache handler threads.
22 4.4 Read-write 21/ Read-write For read-write benchmarks, we had to create oltp_nontran.lua, which is the same sysbench benchmark as oltp.lua, except that it does the reads outside of the transaction and does only the writes in transaction, so caching can have an effect on read. The rest of the benchmarking setup is the same as the read-only case. In this benchmark, we did not utilize ScaleArc's read-write split feature, which could make the results better if we used multiple database servers Sysbench throughput Similarly to the read-only case, at a low concurrency, the overhead of ScaleArc is coming from the additional network roundtrip. At the optimal concurrency, the overhead is barely measurable (the dots are
23 4.4 Read-write 22/31 plotted practically on top of each other).
24 4.4 Read-write 23/ Sysbench response time
25 4.4 Read-write 24/31 The case is pretty similar with the response times as in the read-only case. Similarly, the second graph is a zoomed version of the first one, which a 250 ms maximum.
26 4.4 Read-write 25/ CPU utilization The CPU utilization graph shows that in this case, the database server's CPU is the bottleneck. What is interesting is that ScaleArc is using less CPU than in the read-only case. This is understandable, since a transaction now contains writes as well, which are expensive on the database side, but they are still just statements to route on the ScaleArc side.
27 4.5 Effects of caching on read-write workload 26/ Effects of caching on read-write workload Measuring caching here is interesting because the workload is no longer read-only of mostly reads. We have a very significant amount of writes. [ 16s] threads: 64, tps: , reads/s: , writes/s: , response time: 45.20ms (95%) For 30k reads, we get 8,5k writes. It's expected that caching won't help as much as in the previous case, because writes can't be cached and while they are in process, the benchmarking threads can't proceed with reads. Please note that this means that roughly 25% of the traffic is write, a typical application scaling out with additional slaves for reads doesn't have this kind of read-to-write ratio.
28 4.5 Effects of caching on read-write workload 27/ Sysbench throughput The first graph shows that in terms of total throughput, caching still helps.
29 4.5 Effects of caching on read-write workload 28/ Sysbench response time
30 4.5 Effects of caching on read-write workload 29/31 Similarly to the read-only case, caching also helps response time, because it reduces the time needed for the read part of the workload.
31 4.5 Effects of caching on read-write workload 30/ CPU utilization
32 5 Conclusion 31/31 This test really stresses the database server's CPU when not caching. With caching on, similarly to the read-only case, the client's workload increases somewhat (but not as much), and the database server's CPU usage decreases significantly. In the last row, the CPU utilization of ScaleArc shows that although it's somewhat higher with caching, it's still not that much higher. From these tests it's visible that caching can still be beneficial even if the write ratio is as high as in this test. 5 Conclusion Engineering is always about making the right tradeoffs. If one wants features that needs a protocol-level load balancer like ScaleArc, the price should be paid in the overhead of Layer 7 parsing and decision making. ScaleArc's engineering team did a great job minimizing this overhead. ScaleArc itself is very well tunable for different workload types (if caching is important, ScaleArc can be tuned for caching - if query rewriting, ScaleArc can be tuned for that).
MySQL Performance Optimization and Troubleshooting with PMM. Peter Zaitsev, CEO, Percona
MySQL Performance Optimization and Troubleshooting with PMM Peter Zaitsev, CEO, Percona In the Presentation Practical approach to deal with some of the common MySQL Issues 2 Assumptions You re looking
More informationMySQL Performance Optimization and Troubleshooting with PMM. Peter Zaitsev, CEO, Percona Percona Technical Webinars 9 May 2018
MySQL Performance Optimization and Troubleshooting with PMM Peter Zaitsev, CEO, Percona Percona Technical Webinars 9 May 2018 Few words about Percona Monitoring and Management (PMM) 100% Free, Open Source
More informationMySQL Database Scalability
MySQL Database Scalability Nextcloud Conference 2016 TU Berlin Oli Sennhauser Senior MySQL Consultant at FromDual GmbH oli.sennhauser@fromdual.com 1 / 14 About FromDual GmbH Support Consulting remote-dba
More informationPerformance Test Results for ScaleArc for MySQL on Aurora RDS Nov ScaleArc. All Rights Reserved. 1
Performance Test Results for ScaleArc for MySQL on Aurora RDS Nov 2016 2016 ScaleArc. All Rights Reserved. 1 ScaleArc for MySQL Aurora RDS Testing ScaleArc has updated its ScaleArc for MySQL database load
More informationInnoDB Scalability Limits. Peter Zaitsev, Vadim Tkachenko Percona Inc MySQL Users Conference 2008 April 14-17, 2008
InnoDB Scalability Limits Peter Zaitsev, Vadim Tkachenko Percona Inc MySQL Users Conference 2008 April 14-17, 2008 -2- Who are the Speakers? Founders of Percona Inc MySQL Performance and Scaling consulting
More informationPerformance improvements in MySQL 5.5
Performance improvements in MySQL 5.5 Percona Live Feb 16, 2011 San Francisco, CA By Peter Zaitsev Percona Inc -2- Performance and Scalability Talk about Performance, Scalability, Diagnostics in MySQL
More informationHow to Fulfill the Potential of InnoDB's Performance and Scalability
How to Fulfill the Potential of InnoDB's Performance and Scalability MySQL Conference & Expo 21 Yasufumi Kinoshita Senior Performance Engineer Percona Inc. MySQLPerformanceBlog.com -2- About me... http://mysqlperformanceblog.com
More informationScaling Without Sharding. Baron Schwartz Percona Inc Surge 2010
Scaling Without Sharding Baron Schwartz Percona Inc Surge 2010 Web Scale!!!! http://www.xtranormal.com/watch/6995033/ A Sharding Thought Experiment 64 shards per proxy [1] 1 TB of data storage per node
More informationImprovements in MySQL 5.5 and 5.6. Peter Zaitsev Percona Live NYC May 26,2011
Improvements in MySQL 5.5 and 5.6 Peter Zaitsev Percona Live NYC May 26,2011 State of MySQL 5.5 and 5.6 MySQL 5.5 Released as GA December 2011 Percona Server 5.5 released in April 2011 Proven to be rather
More informationInnodb Performance Optimization
Innodb Performance Optimization Most important practices Peter Zaitsev CEO Percona Technical Webinars December 20 th, 2017 1 About this Presentation Innodb Architecture and Performance Optimization 3h
More informationWhat s New in MySQL 5.7 Geir Høydalsvik, Sr. Director, MySQL Engineering. Copyright 2015, Oracle and/or its affiliates. All rights reserved.
What s New in MySQL 5.7 Geir Høydalsvik, Sr. Director, MySQL Engineering Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes
More informationWhat's new in MySQL 5.5? Performance/Scale Unleashed
What's new in MySQL 5.5? Performance/Scale Unleashed Mikael Ronström Senior MySQL Architect The preceding is intended to outline our general product direction. It is intended for
More informationSolid State Disk Benchmarking
Solid State Disk Benchmarking Matt Yonkovit Senior Consultant, MySQL AB This document shows performance benchmark tests using a 32GB Mtron MSP Solid State Disk Drive in a Linux Environment. The focus of
More informationPhxSQL: A High-Availability & Strong-Consistency MySQL Cluster. Ming
PhxSQL: A High-Availability & Strong-Consistency MySQL Cluster Ming CHEN@WeChat Why PhxSQL Highly expected features for MySql cluster Availability and consistency in MySQL cluster Master-slaves replication
More informationChoosing Hardware and Operating Systems for MySQL. Apr 15, 2009 O'Reilly MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc
Choosing Hardware and Operating Systems for MySQL Apr 15, 2009 O'Reilly MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc -2- We will speak about Choosing Hardware Choosing Operating
More informationAccelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan
Accelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan Agenda OLTP status quo Goal System environments Tuning and optimization MySQL Server results Percona Server
More informationMySQL 8.0 Performance: InnoDB Re-Design
MySQL 8.0 Performance: InnoDB Re-Design Insert Picture Here Dimitri KRAVTCHUK MySQL Performance Architect @Oracle Copyright 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection
More informationThe Role of Database Aware Flash Technologies in Accelerating Mission- Critical Databases
The Role of Database Aware Flash Technologies in Accelerating Mission- Critical Databases Gurmeet Goindi Principal Product Manager Oracle Flash Memory Summit 2013 Santa Clara, CA 1 Agenda Relational Database
More informationTechnology Overview ScaleArc. All Rights Reserved.
2014 ScaleArc. All Rights Reserved. Contents Contents...1 ScaleArc Overview...1 Who ScaleArc Helps...2 Historical Database Challenges...3 Use Cases and Projects...5 Sample ScaleArc Customers...5 Summary
More informationOptimizing MySQL Configuration
Optimizing MySQL Configuration 10 November,2016 Peter Zaitsev CEO, Percona Agenda MySQL Configuration Tuning Basics What s new with MySQL Looking at Most Important Options 2 Things to Know About MySQL
More informationArchitectural Differences nc. DRAM devices are accessed with a multiplexed address scheme. Each unit of data is accessed by first selecting its row ad
nc. Application Note AN1801 Rev. 0.2, 11/2003 Performance Differences between MPC8240 and the Tsi106 Host Bridge Top Changwatchai Roy Jenevein risc10@email.sps.mot.com CPD Applications This paper discusses
More informationInnoDB: Status, Architecture, and Latest Enhancements
InnoDB: Status, Architecture, and Latest Enhancements O'Reilly MySQL Conference, April 14, 2011 Inaam Rana, Oracle John Russell, Oracle Bios Inaam Rana (InnoDB / MySQL / Oracle) Crash recovery speedup
More informationScaleArc for SQL Server
Solution Brief ScaleArc for SQL Server Overview Organizations around the world depend on SQL Server for their revenuegenerating, customer-facing applications, running their most business-critical operations
More informationRocksDB Key-Value Store Optimized For Flash
RocksDB Key-Value Store Optimized For Flash Siying Dong Software Engineer, Database Engineering Team @ Facebook April 20, 2016 Agenda 1 What is RocksDB? 2 RocksDB Design 3 Other Features What is RocksDB?
More informationOPTIMIZING MYSQL SERVER ON SUN X64 SERVERS AND STORAGE. Luojia Chen, ISV Engineering. Sun BluePrints Online February 2008
OPTIMIZING MYSQL SERVER ON SUN X64 SERVERS AND STORAGE Luojia Chen, ISV Engineering Sun BluePrints Online February 2008 Part No 820-4498-10 Revision 1.0, 2/20/08 Edition: February 2008 Sun Microsystems,
More informationEverything You Need to Know About MySQL Group Replication
Everything You Need to Know About MySQL Group Replication Luís Soares (luis.soares@oracle.com) Principal Software Engineer, MySQL Replication Lead Copyright 2017, Oracle and/or its affiliates. All rights
More informationPractical MySQL Performance Optimization. Peter Zaitsev, CEO, Percona July 20 th, 2016 Percona Technical Webinars
Practical MySQL Performance Optimization Peter Zaitsev, CEO, Percona July 20 th, 2016 Percona Technical Webinars In This Presentation We ll Look at how to approach Performance Optimization Discuss Practical
More informationMySQL High Availability
MySQL High Availability And other stuff worth talking about Peter Zaitsev CEO Moscow MySQL Users Group Meetup July 11 th, 2017 1 Few Words about Percona 2 Percona s Purpose To Champion Unbiased Open Source
More informationBest Practices. Deploying Optim Performance Manager in large scale environments. IBM Optim Performance Manager Extended Edition V4.1.0.
IBM Optim Performance Manager Extended Edition V4.1.0.1 Best Practices Deploying Optim Performance Manager in large scale environments Ute Baumbach (bmb@de.ibm.com) Optim Performance Manager Development
More informationOptimizing MySQL Configuration. Peter Zaitsev,CEO Technical Webinars Series March 2012
Optimizing MySQL Configuration Peter Zaitsev,CEO Technical Webinars Series March 2012 Agenda MySQL Configuration Tuning Basics Tools to Configure MySQL Looking at Most Important Options Things to know
More informationHow To Rock with MyRocks. Vadim Tkachenko CTO, Percona Webinar, Jan
How To Rock with MyRocks Vadim Tkachenko CTO, Percona Webinar, Jan-16 2019 Agenda MyRocks intro and internals MyRocks limitations Benchmarks: When to choose MyRocks over InnoDB Tuning for the best results
More informationMySQL Performance Improvements
Taking Advantage of MySQL Performance Improvements Baron Schwartz, Percona Inc. Introduction About Me (Baron Schwartz) Author of High Performance MySQL 2 nd Edition Creator of Maatkit, innotop, and so
More informationSwitching to Innodb from MyISAM. Matt Yonkovit Percona
Switching to Innodb from MyISAM Matt Yonkovit Percona -2- DIAMOND SPONSORSHIPS THANK YOU TO OUR DIAMOND SPONSORS www.percona.com -3- Who We Are Who I am Matt Yonkovit Principal Architect Veteran of MySQL/SUN/Percona
More informationImproving overall Robinhood performance for use on large-scale deployments Colin Faber
Improving overall Robinhood performance for use on large-scale deployments Colin Faber 2017 Seagate Technology LLC 1 WHAT IS ROBINHOOD? Robinhood is a versatile policy engine
More informationReplication features of 2011
FOSDEM 2012 Replication features of 2011 What they were How to get them How to use them Sergey Petrunya MariaDB MySQL Replication in 2011: overview Notable events, chronologically: MySQL 5.5 GA (Dec 2010)
More informationOptimizing MySQL Configuration. Peter Zaitsev,CEO OSCON 2012, Portland,OR July 20, 2012
Optimizing MySQL Configuration Peter Zaitsev,CEO OSCON 2012, Portland,OR July 20, 2012 Agenda Approach to getting great MySQL Configuration Types of Configuration Options Tools to Configure MySQL Looking
More informationInnodb Architecture and Performance Optimization
Innodb Architecture and Performance Optimization MySQL 5.7 Edition Peter Zaitsev April 8, 206 Why Together? 2 Advanced Performance Optimization Needs Architecture Knowledge 2 Right Level 3 Focus on Details
More informationSystem Characteristics
System Characteristics Performance is influenced by characteristics of the system hosting the database server, for example: - Disk input/output (I/O) speed. - Amount of memory available. - Processor speed.
More informationHighly Available Database Architectures in AWS. Santa Clara, California April 23th 25th, 2018 Mike Benshoof, Technical Account Manager, Percona
Highly Available Database Architectures in AWS Santa Clara, California April 23th 25th, 2018 Mike Benshoof, Technical Account Manager, Percona Hello, Percona Live Attendees! What this talk is meant to
More informationTo Shard or Not to Shard That is the question! Peter Zaitsev April 21, 2016
To Shard or Not to Shard That is the question! Peter Zaitsev April 21, 2016 Story Let s start with the story 2 First things to decide Before you decide how to shard you d best understand whether or not
More informationMultiprocessor System. Multiprocessor Systems. Bus Based UMA. Types of Multiprocessors (MPs) Cache Consistency. Bus Based UMA. Chapter 8, 8.
Multiprocessor System Multiprocessor Systems Chapter 8, 8.1 We will look at shared-memory multiprocessors More than one processor sharing the same memory A single CPU can only go so fast Use more than
More informationA Fast and High Throughput SQL Query System for Big Data
A Fast and High Throughput SQL Query System for Big Data Feng Zhu, Jie Liu, and Lijie Xu Technology Center of Software Engineering, Institute of Software, Chinese Academy of Sciences, Beijing, China 100190
More informationMassive Scalability With InterSystems IRIS Data Platform
Massive Scalability With InterSystems IRIS Data Platform Introduction Faced with the enormous and ever-growing amounts of data being generated in the world today, software architects need to pay special
More informationXtraDB 5.7: Key Performance Algorithms. Laurynas Biveinis Alexey Stroganov Percona
XtraDB 5.7: Key Performance Algorithms Laurynas Biveinis Alexey Stroganov Percona firstname.lastname@percona.com XtraDB 5.7 Key Performance Algorithms Focus on the buffer pool, flushing, the doublewrite
More informationHive Metadata Caching Proposal
Hive Metadata Caching Proposal Why Metastore Cache During Hive 2 benchmark, we find Hive metastore operation take a lot of time and thus slow down Hive compilation. In some extreme case, it takes much
More informationMultiprocessor Systems. COMP s1
Multiprocessor Systems 1 Multiprocessor System We will look at shared-memory multiprocessors More than one processor sharing the same memory A single CPU can only go so fast Use more than one CPU to improve
More informationEvaluation of Chelsio Terminator 6 (T6) Unified Wire Adapter iscsi Offload
November 2017 Evaluation of Chelsio Terminator 6 (T6) Unified Wire Adapter iscsi Offload Initiator and target iscsi offload improve performance and reduce processor utilization. Executive Summary The Chelsio
More informationMultiprocessor Systems. Chapter 8, 8.1
Multiprocessor Systems Chapter 8, 8.1 1 Learning Outcomes An understanding of the structure and limits of multiprocessor hardware. An appreciation of approaches to operating system support for multiprocessor
More informationInnodb Architecture and Performance Optimization. Peter Zaitsev, CEO Percona 25 September 2017
Innodb Architecture and Performance Optimization Peter Zaitsev, CEO Percona 25 September 2017 Why Together? Advanced Performance Optimization Needs Architecture Knowledge 2 Right Level Focus on Details
More informationPolarDB. Cloud Native Alibaba. Lixun Peng Inaam Rana Alibaba Cloud Team
PolarDB Cloud Native DB @ Alibaba Lixun Peng Inaam Rana Alibaba Cloud Team Agenda Context Architecture Internals HA Context PolarDB is a cloud native DB offering Based on MySQL-5.6 Uses shared storage
More informationExadata X3 in action: Measuring Smart Scan efficiency with AWR. Franck Pachot Senior Consultant
Exadata X3 in action: Measuring Smart Scan efficiency with AWR Franck Pachot Senior Consultant 16 March 2013 1 Exadata X3 in action: Measuring Smart Scan efficiency with AWR Exadata comes with new statistics
More informationBottleneck Hunters: How Schooner increased MySQL throughput by more than 800% Jeremy Cole
Bottleneck Hunters: How Schooner increased MySQL throughput by more than 800% Jeremy Cole On the genesis of Schooner: Hardware is massively under-utilized I/O has long
More informationPractical MySQL Performance Optimization. Peter Zaitsev, CEO, Percona July 02, 2015 Percona Technical Webinars
Practical MySQL Performance Optimization Peter Zaitsev, CEO, Percona July 02, 2015 Percona Technical Webinars In This Presentation We ll Look at how to approach Performance Optimization Discuss Practical
More informationSEDA: An Architecture for Well-Conditioned, Scalable Internet Services
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services Matt Welsh, David Culler, and Eric Brewer Computer Science Division University of California, Berkeley Operating Systems Principles
More informationDeploying MySQL in Production Daniel Kowalewski Senior Technical Operations Engineer, Percona
Deploying MySQL in Production Daniel Kowalewski Senior Technical Operations Engineer, Percona daniel.kowalewski@percona.com 1 Deploying MySQL in Production Installation Configuration (OS and MySQL) Backups
More informationIX: A Protected Dataplane Operating System for High Throughput and Low Latency
IX: A Protected Dataplane Operating System for High Throughput and Low Latency Belay, A. et al. Proc. of the 11th USENIX Symp. on OSDI, pp. 49-65, 2014. Reviewed by Chun-Yu and Xinghao Li Summary In this
More informationWhich technology to choose in AWS?
Which technology to choose in AWS? RDS / Aurora / Roll-your-own April 17, 2018 Daniel Kowalewski Senior Technical Operations Engineer Percona 1 2017 Percona AWS MySQL options RDS for MySQL Aurora MySQL
More informationHandlersocket. Ryan Lowe Percona Live London 2011
Handlersocket Ryan Lowe Percona Live London 2011 Agenda What is Handlersocket mysqlds vs libhsclient How much does it save? How is it used? When can it be used? Other nosql alternatives for MySQL What
More informationAerospike Scales with Google Cloud Platform
Aerospike Scales with Google Cloud Platform PERFORMANCE TEST SHOW AEROSPIKE SCALES ON GOOGLE CLOUD Aerospike is an In-Memory NoSQL database and a fast Key Value Store commonly used for caching and by real-time
More informationUsing PostgreSQL in Tantan - From 0 to 350bn rows in 2 years
Using PostgreSQL in Tantan - From 0 to 350bn rows in 2 years Victor Blomqvist vb@viblo.se Tantan ( 探探 ) December 2, PGConf Asia 2016 in Tokyo tantanapp.com 1 Sweden - Tantan - Tokyo 10 Million 11 Million
More informationA Brief Introduction of TiDB. Dongxu (Edward) Huang CTO, PingCAP
A Brief Introduction of TiDB Dongxu (Edward) Huang CTO, PingCAP About me Dongxu (Edward) Huang, Cofounder & CTO of PingCAP PingCAP, based in Beijing, China. Infrastructure software engineer, open source
More informationAccelerate Applications Using EqualLogic Arrays with directcache
Accelerate Applications Using EqualLogic Arrays with directcache Abstract This paper demonstrates how combining Fusion iomemory products with directcache software in host servers significantly improves
More informationDeploying MySQL in Production
Deploying MySQL in Production Daniel Kowalewski (Percona) Senior Technical Operations Engineer daniel.kowalewski@percona.com @dankow Deploying MySQL in Production Installation Configuration (OS and MySQL)
More informationScaling App Engine Applications. Justin Haugh, Guido van Rossum May 10, 2011
Scaling App Engine Applications Justin Haugh, Guido van Rossum May 10, 2011 First things first Justin Haugh Software Engineer Systems Infrastructure jhaugh@google.com Guido Van Rossum Software Engineer
More informationMigrating To MySQL The Live Database Upgrade Guide
Migrating To MySQL 5.7 - The Live Database Upgrade Guide October 4, 2016 Krzysztof Książek Severalnines krzysztof@severalnines.com 1 Agenda! Why upgrading to MySQL 5.7?! Preparing an upgrade - changes
More informationOptimizing MySQL Configuration. Peter Zaitsev,CEO Percona Live, Washington DC 11 January 2012
Optimizing MySQL Configuration Peter Zaitsev,CEO Percona Live, Washington DC 11 January 2012 Agenda Approach to getting great MySQL Configuration Types of Configuration Options Tools to Configure MySQL
More informationReal World Web Scalability. Ask Bjørn Hansen Develooper LLC
Real World Web Scalability Ask Bjørn Hansen Develooper LLC Hello. 28 brilliant methods to make your website keep working past $goal requests/transactions/sales per second/hour/day Requiring minimal extra
More informationNetApp AFF A300 Review
StorageReview StorageReview takes an in-depth look at features, and performance of NetApp AFF A300 storage array. 1395 Crossman Ave Sunnyvale, CA 94089 United States Table of Contents INTRODUCTION... 3-5
More informationFuxiSort. Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang Alibaba Group Inc
Fuxi Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang Alibaba Group Inc {jiamang.wang, yongjun.wyj, hua.caihua, zhipeng.tzp, zhiqiang.lv,
More informationMySQL Performance Tuning 101
MySQL Performance Tuning 101 Hands-on-Lab Mirko Ortensi Senior Support Engineer MySQL Support @ Oracle October 3, 2017 Copyright 2017, Oracle and/or its affiliates. All rights reserved. Safe Harbor Statement
More informationMySQL Replication. Rick Golba and Stephane Combaudon April 15, 2015
MySQL Replication Rick Golba and Stephane Combaudon April 15, 2015 Agenda What is, and what is not, MySQL Replication Replication Use Cases Types of replication Replication lag Replication errors Replication
More informationAccelerating OLTP performance with NVMe SSDs
Accelerating OLTP performance with NVMe SSDs Veronica Lagrange Changho Choi Vijay Balakrishnan Memory Solutions Lab. Samsung Semiconductor, Inc. 9/01/2016 Version 3.0 Page 1 Table of Contents 1. Introduction...
More informationPercona XtraDB Cluster
Percona XtraDB Cluster Ensure High Availability Presenter Karthik P R CEO Mydbops www.mydbops.com info@mydbops.com Mydbops Mydbops is into MySQL/MongoDB Support and Consulting. It is founded by experts
More informationMySQL High Availability Solutions. Alex Poritskiy Percona
MySQL High Availability Solutions Alex Poritskiy Percona The Five 9s of Availability Clustering & Geographical Redundancy Clustering Technologies Replication Technologies Well-Managed disasters power failures
More informationRecovering Disk Storage Metrics from low level Trace events
Recovering Disk Storage Metrics from low level Trace events Progress Report Meeting May 05, 2016 Houssem Daoud Michel Dagenais École Polytechnique de Montréal Laboratoire DORSAL Agenda Introduction and
More informationGFS-python: A Simplified GFS Implementation in Python
GFS-python: A Simplified GFS Implementation in Python Andy Strohman ABSTRACT GFS-python is distributed network filesystem written entirely in python. There are no dependencies other than Python s standard
More informationA Guide to Architecting the Active/Active Data Center
White Paper A Guide to Architecting the Active/Active Data Center 2015 ScaleArc. All Rights Reserved. White Paper The New Imperative: Architecting the Active/Active Data Center Introduction With the average
More informationManual Mysql Query Cache Hit Rate 0
Manual Mysql Query Cache Hit Rate 0 B) why the Table cache hit rate is only 56% How can i achieve better cache hit rate? (OK) Currently running supported MySQL version 5.5.43-0+deb7u1-log or complex to
More informationWhite Paper. Major Performance Tuning Considerations for Weblogic Server
White Paper Major Performance Tuning Considerations for Weblogic Server Table of Contents Introduction and Background Information... 2 Understanding the Performance Objectives... 3 Measuring your Performance
More informationMigrating to XtraDB Cluster 2014 Edition
Migrating to XtraDB Cluster 2014 Edition Jay Janssen Managing Consultant Overview of XtraDB Cluster Percona Server + Galera Cluster of Innodb nodes Readable and Writable Virtually Synchronous All data
More informationScalability of web applications
Scalability of web applications CSCI 470: Web Science Keith Vertanen Copyright 2014 Scalability questions Overview What's important in order to build scalable web sites? High availability vs. load balancing
More informationWhy Choose Percona Server For MySQL? Tyler Duzan
Why Choose Percona Server For MySQL? Tyler Duzan Product Manager Who Am I? My name is Tyler Duzan Formerly an operations engineer for more than 12 years focused on security and automation Now a Product
More informationAzure database performance Azure performance measurements February 2017
dbwatch report 1-2017 Azure database performance Azure performance measurements February 2017 Marek Jablonski, CTO dbwatch AS Azure database performance Introduction The popular image of cloud services
More informationColumn Stores vs. Row Stores How Different Are They Really?
Column Stores vs. Row Stores How Different Are They Really? Daniel J. Abadi (Yale) Samuel R. Madden (MIT) Nabil Hachem (AvantGarde) Presented By : Kanika Nagpal OUTLINE Introduction Motivation Background
More information- SLED: single large expensive disk - RAID: redundant array of (independent, inexpensive) disks
RAID and AutoRAID RAID background Problem: technology trends - computers getting larger, need more disk bandwidth - disk bandwidth not riding moore s law - faster CPU enables more computation to support
More information1 Copyright 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8
1 Copyright 2011, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 8 ADVANCED MYSQL REPLICATION ARCHITECTURES Luís
More informationBullet Cache. Balancing speed and usability in a cache server. Ivan Voras
Bullet Cache Balancing speed and usability in a cache server Ivan Voras What is it? People know what memcached is... mostly Example use case: So you have a web page which is just dynamic
More informationPerformance comparisons and trade-offs for various MySQL replication schemes
Performance comparisons and trade-offs for various MySQL replication schemes Darpan Dinker VP Engineering Brian O Krafka, Chief Architect Schooner Information Technology, Inc. http://www.schoonerinfotech.com/
More informationUpgrading MySQL Best Practices. Apr 11-14, 2011 MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc
Upgrading MySQL Best Practices Apr 11-14, 2011 MySQL Conference and Expo Santa Clara,CA by Peter Zaitsev, Percona Inc MySQL Upgrade How many of you have performed MySQL upgrade? Home many of you have done
More informationPerformance Benchmark and Capacity Planning. Version: 7.3
Performance Benchmark and Capacity Planning Version: 7.3 Copyright 215 Intellicus Technologies This document and its content is copyrighted material of Intellicus Technologies. The content may not be copied
More information0-1 Million in 46 Days Scaling a Facebook Application in Rails
0-1 Million in 46 Days Scaling a Facebook Application in Rails Ikai Lan Linkedin Ikai Lan From 0 to 1,000,000 in 46 Days: Scaling a Facebook Application in Rails Slide 1 Hi! I m Ikai Lan Ikai Lan From
More informationForecasting MySQL Scalability. Baron Schwartz O'Reilly MySQL Conference & Expo 2011
Forecasting MySQL Scalability Baron Schwartz O'Reilly MySQL Conference & Expo 2011 Consulting Support Training Development For MySQL Percona Server Replaces MySQL Faster Queries More Consistent More Measurable
More informationSCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT
SCALING UP VS. SCALING OUT IN A QLIKVIEW ENVIRONMENT QlikView Technical Brief February 2012 qlikview.com Introduction When it comes to the enterprise Business Discovery environments, the ability of the
More informationSSD/Flash for Modern Databases. Peter Zaitsev, CEO, Percona November 1, 2014 Highload Moscow,Russia
SSD/Flash for Modern Databases Peter Zaitsev, CEO, Percona November 1, 2014 Highload++ 2014 Moscow,Russia Percona We love Open Source Software Percona Server Percona Xtrabackup Percona XtraDB Cluster Percona
More informationCISC 7610 Lecture 2b The beginnings of NoSQL
CISC 7610 Lecture 2b The beginnings of NoSQL Topics: Big Data Google s infrastructure Hadoop: open google infrastructure Scaling through sharding CAP theorem Amazon s Dynamo 5 V s of big data Everyone
More informationIBM V7000 Unified R1.4.2 Asynchronous Replication Performance Reference Guide
V7 Unified Asynchronous Replication Performance Reference Guide IBM V7 Unified R1.4.2 Asynchronous Replication Performance Reference Guide Document Version 1. SONAS / V7 Unified Asynchronous Replication
More informationChoosing a MySQL High Availability Solution. Marcos Albe, Percona Inc. Live Webinar June 2017
Choosing a MySQL High Availability Solution Marcos Albe, Percona Inc. Live Webinar June 2017 Agenda What is availability Components to build an HA solution HA options in the MySQL ecosystem Failover/Routing
More informationDistributed File Systems
Distributed File Systems Today l Basic distributed file systems l Two classical examples Next time l Naming things xkdc Distributed File Systems " A DFS supports network-wide sharing of files and devices
More informationWHITE PAPER AGILOFT SCALABILITY AND REDUNDANCY
WHITE PAPER AGILOFT SCALABILITY AND REDUNDANCY Table of Contents Introduction 3 Performance on Hosted Server 3 Figure 1: Real World Performance 3 Benchmarks 3 System configuration used for benchmarks 3
More informationLoad Testing Tools. for Troubleshooting MySQL Concurrency Issues. May, 23, 2018 Sveta Smirnova
Load Testing Tools for Troubleshooting MySQL Concurrency Issues May, 23, 2018 Sveta Smirnova Introduction This is very personal webinar No intended use No best practices No QA-specific tools Real life
More information