Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MongoDB Days UK: Scaling MongoDB with Docker and cgroups

5,038 views

Published on

Presented by Marco Bonezzi, Technical Services Engineer, MongoDB

Experience level: Advanced

There is no doubt that users always look for new ways to scale their applications. Along this trend, the use of Docker as the container technology is becoming more frequent to deploy and easily manage complex architectures like sharded clusters in MongoDB. One of the challenges of scaling MongoDB using containers technology is to understand how to implement your cluster while monitoring and controlling resource usage of each component. This session focuses on combining MongoDB sharded clusters and Docker containers with cgroups to successfully control resource usage of a MongoDB cluster with the WiredTiger storage engine.

Published in: Technology

MongoDB Days UK: Scaling MongoDB with Docker and cgroups

  1. 1. Scaling MongoDB with Docker and cgroups Marco Bonezzi Technical Services Engineer, MongoDB marco@mongodb.com @marcobonezzi
  2. 2. 2 Agenda •  MongoDB and WiredTiger •  Why should you use Docker with MongoDB? •  Scaling MongoDB with Docker •  Results
  3. 3. P S S config S S P S S SHARD2 SHARD1 mongos
  4. 4. MongoDB and WiredTiger
  5. 5. 5 MongoDB 3.0 and WiredTiger MongoDB Storage Engine API + WiredTiger storage engine Main features •  Document-level concurrency control •  Durability •  Compression •  EncrypHon at rest (3.2)
  6. 6. 6 WiredTiger increased scalability •  MulH-core scaling •  Lock-free algorithms (hazard-pointers) •  No in-place update (skip lists) •  Eliminate blocking with concurrency control
  7. 7. 7 WiredTiger increased scalability •  Higher throughput on write and updates (skip lists)
  8. 8. 8 Best prac>ces for WiredTiger •  XFS filesystem •  # concurrent ac+ve opera+ons •  Best throughput when <= #CPU •  Memory and WiredTiger cache •  storage.wiredTiger.engineConfig.cacheSizeGB
  9. 9. 9 MongoDB Memory and WiredTiger cache cacheSizeGB = max(1GB, 0.5 * memory) WiredTiger cache: Used for data and indexes only
  10. 10. 10 MongoDB Memory and WiredTiger cache WiredTiger cache: Used to store the current working set cacheSizeGB = max(1GB, 0.5 * memory)
  11. 11. 11 MongoDB Memory and WiredTiger cache MongoDB Memory: mongod process: connecHons, aggregaHons, mapReduce, etc cacheSizeGB = max(1GB, 0.5 * memory) Total memory = mem(mongod) + cacheSizeGB
  12. 12. 12 Containerizing MongoDB •  MongoDB dockerfile (or create your own) hPps://github.com/sisteming/mongodocker/ [mongodb.docker] •  Generic mongod.conf configuraHon file •  Automate your deployment for scaling: •  # mongods •  Ports and network interfaces •  Single or mulHple hosts •  CPU or memory limits
  13. 13. 13 Summary •  MongoDB with WiredTiger: •  Higher throughput with increased scalability •  AddiHonal features: compression, encrypHon •  WiredTiger cache memory •  MongoDB on Docker: •  Generic image •  Automate to scale
  14. 14. Why should you use Docker for MongoDB?
  15. 15. 15 Docker According to docker.com: How can this be useful for my MongoDB deployments? (That’s why you are here today)
  16. 16. 16 Why should you use Docker for MongoDB? Build •  and define your container based on OS, mongodb release or configuraHon •  Build once, deploy everywhere
  17. 17. 17 Why should you use Docker for MongoDB? Ship •  Deploy the same image in Dev, Pre-prod (or even Prod!) with the same setup •  MongoDB standalone, Replica Sets or cluster with mulHple shards from the same image
  18. 18. 18 Why should you use Docker for MongoDB? Run •  Your mongoDB processes isolated from the rest of processes on the system •  Isolate the resources for co-located mongodb processes
  19. 19. 19 VS
  20. 20. 20 Resource management Cgroups ImplementaHon on Docker
  21. 21. 21 Resource management Cgroups ImplementaHon on Docker --cpu-shares --cpuset-cpus --memory --blkio-weight --net
  22. 22. 22 Summary Using Docker for MongoDB is useful for many reasons: •  Build once, deploy everywhere •  Environment portability •  Mongod process isolaHon •  Faster deployments of complex clusters •  Resource management with cgroups
  23. 23. Scaling MongoDB with Docker config S S P S S P S S SHARD2 SHARD1 mongos
  24. 24. 24 Use cases of MongoDB and Docker Microsharding •  MulHple co-located mongod instances •  Each mongod = shard •  AggregaHons Mul>ple instances •  Control co-located mongod processes on same server •  Different instances / uses
  25. 25. 25 Memory limit MEM = ($TOTAL_MEMORY - 2048) / $NUM_MONGOD WiredTiger cache = $MEM / 2
  26. 26. 26 CPU limit NUMBER = from 0 to MAX_CPU_CORES (i.e. with 32 cores -> --cpuset = 0, 16)
  27. 27. 27 Docker + cgroups: Memory mapping WiredTiger cache size: defined for each shard 50% MongoDB memory – 50% WiredTiger cache
  28. 28. 28 MongoDB on Docker + cgroups: CPU mapping Each shard mapped to 1 (or more) core (using --cpuset-cpus) core0 core1 core2 core3 core4 core5 core6 core7 core8 core9 core10 core11 core12 core13 core14 core15
  29. 29. 29 Resource usage with Docker •  Understanding resource usage: •  Container stats available through Docker remote API: GET /containers/(id)/stats echo -e "GET /containers/$id/stats HTTP/1.0rn" | nc -U /var/run/docker.sock
  30. 30. 30 Summary •  Uses of scaling MongoDB with Docker •  LimiHng CPU on your container •  Defining memory and WiredTiger cache limits •  Resource usage with Docker
  31. 31. Results
  32. 32. 32 Target and scenarios Scalability by microsharding MongoDB with WiredTiger using docker (and cgroups) •  Main test scenarios: – Sharded cluster with P/S/S ReplicaSet •  From 2 up to 16 shards – Each scenario: •  number of threads: 8, 16, 32 •  Write/Read raHo: 95/5 •  memory and WiredTiger cache
  33. 33. 33 Workload POCDriver (https://github.com/johnlpage/POCDriver) •  Easy to use –  java -jar POCDriver.jar -d 610 -c mongoDB:// node1:37019 -o test.log -i 95 -t 10 -k 5 –e •  Automatic collection sharding with even distribution
  34. 34. 34 Workload results summary Scenario A MEM=2GB WiredTiger cache = 1GB Scenario B MEM=32GB/$NUM_SHARDS WiredTiger cache = $MEM/2 (GB)
  35. 35. 35 Total Inserts
  36. 36. 36 Inserts/second
  37. 37. 37 Workload results summary 3 x c3x4large AWS instances: 16 cores 32 GB ram SSD volumes 0 10 20 30 40 50 0 2 4 6 8 10 12 14 16 18 Millions Total Inserts vs #shards Total Inserts 0 10 20 30 40 50 0 2 4 6 8 10 12 14 16 18 Millions Total Inserts vs #shards Total Inserts Scenario A MEM=2GB WiredTiger cache = 1GB Scenario B MEM=32GB/$NUM_SHARDS WiredTiger cache = $MEM/2 (GB)
  38. 38. Summary
  39. 39. 39 Keys for scaling MongoDB and WiredTiger with Docker •  Start from a generic image, automate to scale •  Set limits to all your containers •  Define –WiredTigerCacheSizeGB on each mongod •  EsHmate and define resource distribuHon for your architecture •  Deploy and test with your own workload
  40. 40. Questions? Thank You! Marco Bonezzi @marcobonezzi marco@mongodb.com
  41. 41. #MDBDays mongodb.com Get your technical ques+ons answered Benjamin Bri3en lounge (3rd floor), 10:00 - 17:00 By appointment only – register in person

×