Looking at those numbers, we clearly see that with flushing disabled, we gained almost 10x performance! And this is with only 10k rows.
Mysql-test-bench | execution time (avg/stddev): 59.9613/0.00 Mysql-test-bench | total time taken by event execution: 59.9613s Mysql-test-bench | total number of events: 19291 Mysql-test-bench | other operations: 38582 (643.01 per sec.) With flush disabled: mysql-test-bench | OLTP test statistics: Mysql-test-bench | execution time (avg/stddev): 59.9995/0.00 Mysql-test-bench | total time taken by event execution: 59.9995s Mysql-test-bench | total number of events: 2195 Mysql-test-bench | reconnects: 0 (0.00 per sec.) Mysql-test-bench | ignored errors: 0 (0.00 per sec.) Mysql-test-bench | other operations: 4390 (73.16 per sec.) Mysql-test-bench | read/write requests: 39510 (658.42 per sec.) Mysql-test-bench | transactions: 2195 (36.58 per sec.) With flush enabled: mysql-test-bench | OLTP test statistics: If you’re skeptical about performance gain after changing just one value from true to false, then let the results below change your mind.Ĭommand to run it: $ docker-compose build I ran it twice: once with flushing enabled (default), and once with flushing disabled. In my test case, I decided to use one thread (I only allocated one core for Docker on my Macbook) and a table with 10,000 rows. This test uses a standard Docker MySQL image without tweaks, and an image with sysbench installed. I created a small test case to check this. $ git add 64-linux/disk/full-sync-on-flushġ file changed, 1 insertion(+), 1 deletion(-)Īctually, someone even placed bash script on gist to make things easier. $ echo false > 64-linux/disk/full-sync-on-flush HEAD is now at cafabd0 Docker started 1475137831 Things will get a lot faster when you type those few lines into your terminal: $ cd ~/Library/Containers//Data/database/ While reading about Docker issues on GitHub, I found a solution provided by djs55.
In this case, you may decide to disable this. If you have a Macbook, even power loss isn’t a threat. In most cases, though, you’ll be using your machine for dev purposes where you don’t care to recreate the database from fixtures. This will guarantee that during power loss or any unexpected event your data will be safe.Īctually, this makes sense - if you decide to setup a database inside Docker for Mac on a production environment… In short, to keep our data safe, every change made in the database needs to be stored on disk in an exact order. Applications, such as databases, that require a strict ordering of writes should use F_FULLFSYNC to ensure that their data is written in the order they expect.” The F_FULLFSYNC fcntl asks the drive to flush all buffered data to permanent storage.
#DOCKER FOR MAC XHYVE MAC OS X#
“For applications that require tighter guarantees about the integrity of their data, Mac OS X provides the F_FULLFSYNC fcntl.
#DOCKER FOR MAC XHYVE FULL#
Docker for Mac and Full Sync on Flush Issueįirst, let’s look at MacOS fsync documentation: At least, as long as you don’t try to do any heavy database work. If you are – for example – a Java developer who uses Docker to run compiled JAR, you may even not notice the difference. Things won’t be as close to bare metal as they are in Linux. Because of this, you need to allocate CPU cores and RAM for the VM. To make all this possible, a light Alpine Linux image is fired up underneath with xhyve MacOS native virtualization. It gives you the whole Docker API available from the terminal, even though Docker itself wasn’t created to work on Macs. Almost.ĭocker for Mac is a pretty smart invention. Are you a Linux user who switched to Mac when you saw that Docker is now available as a native Mac app? Have you heard how great Docker is and want to give it a try? Did you think that you could just take your Docker Compose file, launch your project, and have everything work out for you? Well… you were right.
0 kommentar(er)
