Submit Search
Upload
MongoDBが遅いときの切り分け方法
•
Download as PPTX, PDF
•
18 likes
•
35,652 views
Tetsutaro Watanabe
Follow
MMAPv1, WiredTigerについても詳細に説明しています
Read less
Read more
Technology
Report
Share
Report
Share
1 of 46
Download now
Recommended
WiredTigerを詳しく説明
WiredTigerを詳しく説明
Tetsutaro Watanabe
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
Recommended
WiredTigerを詳しく説明
WiredTigerを詳しく説明
Tetsutaro Watanabe
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
DockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
Tetsutaro Watanabe
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
MongoDBのアレをアレする
MongoDBのアレをアレする
Akihiro Kuwano
人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with Karate
Takanori Suzuki
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
Masakazu Matsushita
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Java仮想マシンの実装技術
Java仮想マシンの実装技術
Kiyokuni Kawachiya
MongoDBの監視
MongoDBの監視
Tetsutaro Watanabe
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
例外設計における大罪
例外設計における大罪
Takuto Wada
MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜
Naruhiko Ogasawara
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
Paxos
Paxos
Preferred Networks
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
じゅん なかざ
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
Akihiro Kuwano
More Related Content
What's hot
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
Tetsutaro Watanabe
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
MongoDBのアレをアレする
MongoDBのアレをアレする
Akihiro Kuwano
人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with Karate
Takanori Suzuki
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
Masakazu Matsushita
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Java仮想マシンの実装技術
Java仮想マシンの実装技術
Kiyokuni Kawachiya
MongoDBの監視
MongoDBの監視
Tetsutaro Watanabe
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
例外設計における大罪
例外設計における大罪
Takuto Wada
MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜
Naruhiko Ogasawara
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
Paxos
Paxos
Preferred Networks
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
What's hot
(20)
がっつりMongoDB事例紹介
がっつりMongoDB事例紹介
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
MongoDBのアレをアレする
MongoDBのアレをアレする
人生がときめくAPIテスト自動化 with Karate
人生がときめくAPIテスト自動化 with Karate
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
Vacuum徹底解説
Vacuum徹底解説
後悔しないもんごもんごの使い方 〜アプリ編〜
後悔しないもんごもんごの使い方 〜アプリ編〜
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Java仮想マシンの実装技術
Java仮想マシンの実装技術
MongoDBの監視
MongoDBの監視
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
例外設計における大罪
例外設計における大罪
MongoDB〜その性質と利用場面〜
MongoDB〜その性質と利用場面〜
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Paxos
Paxos
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
Similar to MongoDBが遅いときの切り分け方法
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
じゅん なかざ
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
Akihiro Kuwano
地方企業がソーシャルゲーム開発を成功させるための10のポイント
地方企業がソーシャルゲーム開発を成功させるための10のポイント
Kentaro Matsui
使ってみた!ioMemoryで実現する噂のAtomic write!
使ってみた!ioMemoryで実現する噂のAtomic write!
IIJ
MongoDB勉強会資料
MongoDB勉強会資料
Hiromune Shishido
シラサギハンズオン 東京
シラサギハンズオン 東京
Yu Ito
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
Tetsutaro Watanabe
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
Hiroaki Kubota
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
Takahiro Inoue
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
infinite_loop
シラサギハンズオン 大阪
シラサギハンズオン 大阪
Yu Ito
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
Akihiro Kuwano
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
じゅん なかざ
20120405 setsunaセミナー
20120405 setsunaセミナー
Takahiro Iwase
Introduction to MongoDB
Introduction to MongoDB
moai kids
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
Yoshinori Matsunobu
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
terurou
ビックデータ処理技術の全体像とリクルートでの使い分け
ビックデータ処理技術の全体像とリクルートでの使い分け
Tetsutaro Watanabe
ioMemoryとAtomic Writeによるデータベース高速化
ioMemoryとAtomic Writeによるデータベース高速化
IIJ
Similar to MongoDBが遅いときの切り分け方法
(20)
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~ (前編)
地方企業がソーシャルゲーム開発を成功させるための10のポイント
地方企業がソーシャルゲーム開発を成功させるための10のポイント
使ってみた!ioMemoryで実現する噂のAtomic write!
使ってみた!ioMemoryで実現する噂のAtomic write!
MongoDB勉強会資料
MongoDB勉強会資料
シラサギハンズオン 東京
シラサギハンズオン 東京
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
ビッグデータ処理データベースの全体像と使い分け - 2017年 Version -
DB tech showcase: 噂のMongoDBその用途は?
DB tech showcase: 噂のMongoDBその用途は?
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
シラサギハンズオン 大阪
シラサギハンズオン 大阪
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
20120405 setsunaセミナー
20120405 setsunaセミナー
Introduction to MongoDB
Introduction to MongoDB
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
ビックデータ処理技術の全体像とリクルートでの使い分け
ビックデータ処理技術の全体像とリクルートでの使い分け
ioMemoryとAtomic Writeによるデータベース高速化
ioMemoryとAtomic Writeによるデータベース高速化
More from Tetsutaro Watanabe
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
Tetsutaro Watanabe
MLOpsはバズワード
MLOpsはバズワード
Tetsutaro Watanabe
ドライブレコーダの動画を使った道路情報の自動差分抽出
ドライブレコーダの動画を使った道路情報の自動差分抽出
Tetsutaro Watanabe
IoTデバイスデータ収集の難しい点
IoTデバイスデータ収集の難しい点
Tetsutaro Watanabe
ドライブレコーダの画像認識による道路情報の自動差分抽出
ドライブレコーダの画像認識による道路情報の自動差分抽出
Tetsutaro Watanabe
先駆者に学ぶ MLOpsの実際
先駆者に学ぶ MLOpsの実際
Tetsutaro Watanabe
データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本と「JapanTaxi」アプリにおける実践例
Tetsutaro Watanabe
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
Tetsutaro Watanabe
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
Tetsutaro Watanabe
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
Tetsutaro Watanabe
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
Tetsutaro Watanabe
ビッグデータ処理データベースの全体像と使い分け 2018年version
ビッグデータ処理データベースの全体像と使い分け 2018年version
Tetsutaro Watanabe
Google Cloud Next '18 Recap/報告会 機械学習関連
Google Cloud Next '18 Recap/報告会 機械学習関連
Tetsutaro Watanabe
巨大なサービスと膨大なデータを支えるプラットフォーム
巨大なサービスと膨大なデータを支えるプラットフォーム
Tetsutaro Watanabe
リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例
Tetsutaro Watanabe
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
Tetsutaro Watanabe
MongoDB3.2の紹介
MongoDB3.2の紹介
Tetsutaro Watanabe
MongoDB World 2014に行ってきた!
MongoDB World 2014に行ってきた!
Tetsutaro Watanabe
More from Tetsutaro Watanabe
(18)
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
MLOpsはバズワード
MLOpsはバズワード
ドライブレコーダの動画を使った道路情報の自動差分抽出
ドライブレコーダの動画を使った道路情報の自動差分抽出
IoTデバイスデータ収集の難しい点
IoTデバイスデータ収集の難しい点
ドライブレコーダの画像認識による道路情報の自動差分抽出
ドライブレコーダの画像認識による道路情報の自動差分抽出
先駆者に学ぶ MLOpsの実際
先駆者に学ぶ MLOpsの実際
データ収集の基本と「JapanTaxi」アプリにおける実践例
データ収集の基本と「JapanTaxi」アプリにおける実践例
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
タクシードライブレコーダーの動画処理MLパイプラインにkubernetesを使ってみた
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるSagemaker+αによる機械学習アプリケーションの本番運用
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
JapanTaxiにおけるML Ops 〜機械学習の開発運用プロセス〜
ビッグデータ処理データベースの全体像と使い分け 2018年version
ビッグデータ処理データベースの全体像と使い分け 2018年version
Google Cloud Next '18 Recap/報告会 機械学習関連
Google Cloud Next '18 Recap/報告会 機械学習関連
巨大なサービスと膨大なデータを支えるプラットフォーム
巨大なサービスと膨大なデータを支えるプラットフォーム
リクルートを支える横断データ基盤と機械学習の適用事例
リクルートを支える横断データ基盤と機械学習の適用事例
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
リクルートテクノロジーズ における EMR の活用とコスト圧縮方法
MongoDB3.2の紹介
MongoDB3.2の紹介
MongoDB World 2014に行ってきた!
MongoDB World 2014に行ってきた!
Recently uploaded
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
sn679259
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
WSO2
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Hiroshi Tomioka
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Recently uploaded
(12)
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
MongoDBが遅いときの切り分け方法
1.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved MongoDBが遅いときの切り分け方法 コンサルタント 渡部 徹太郎 1
2.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 自己紹介 2 {"ID" :"fetaro" "名前":"渡部 徹太郎" "研究":"東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事":{前職:["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB,NoSQL"], 現職:["大手Web企業の横断分析基盤,Exadata,Hortonworks,EMR"] 副業:["MongoDBコンサルタント" ]} "エディタ":"emacs派", "趣味": ["自宅サーバ","麻雀"] }
3.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved はじめに MongoDBは速い? • MongoDBはNoSQLだからRDBより速い? • シャーディングすれば単体構成より速い? 3
4.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved はじめに MongoDBは速い?→ケースに依る • MongoDBはNoSQLだからRDBより速い わけではない – RDBとは提供している機能が違う • トランザクション、JOIN、副問合せ等のRDBで遅くなりがちな 複雑なクエリはMongoDBは提供していない • データモデルが違う、保証する整合性が違う – シンプルなクエリであればRDBとMongoDBでそれほど差はな い • MongoDBはオーバーヘッドが少ない分速いが • 結局はディスクIOをどれだけ減らせるか • シャーディングすれば単体構成より速い とは限らない – ボトルネックが分散するようにシャーディングを組まないとい けない – データだけ分散しても駄目。クエリの分散まで考える必要あり – クエリが分散してもボトルネックが解消しないと駄目。 • 例)ネットワークネックならばIOが減っても意味なし 4
5.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved はじめに MongoDBを速くしたければRDBを勉強すべき • MongoDBだから特別なことはほとんどない • MongoDBはRDBに似ている – CassandraやDynamoDB 等はRDBと大きく違う • 8割はRDBのパフォーマンスチューニングの知識でカバーで きる – インデックス、クエリ最適化、キャッシュ、データ圧縮、WAL、 リードレプリカ、パーティショニング • 残り2割はMongoDB特有 – データ構造(JSON)が性能に与える影響 – シャーディング 今回の発表は、RDBにも通用する一般的な話が多いです 5
6.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved アジェンダ • 性能問題との向き合い方 • 解くべき問題の明確化 • 根本原因の特定 • IOボトルネックの解消 – MMAPv1の場合 – WiredTigerの場合 6
7.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 性能問題との向き合い方 7
8.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 性能問題を考える場合の思考順序 1. 解くべき問題の明確化 – 本当にMongoDBが遅いのか? • アプリやネットワークに問題はないか – どのクエリが遅いのか? • 読み込み, 書き込み, 集計 – 何を改善したいのか(性能要件の明確化) • レスポンスタイム,スループット 2. 根本原因の特定 – リソースが枯渇しているのか? • CPU, メモリ/ディスク, NW帯域 – 非効率な処理をしていないか? • ロック開放待ち、フェッチ、NWラウンドトリップ 3. 根本原因の解消 – リソース枯渇の場合 1. 単体構成の性能を最大限まで上げる→ 8割これでいける! 2. リードレプリカ→おまけ 3. シャーディング→最後の手段 – 処理が非効率の場合 • アプリを見直す 8
9.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 性能問題調査でよくある間違い • よくある勘違い – CPU使用率が高すぎることが原因だ! • →いいことです – メモリ使用率が高すぎることが原因だ! • →溢れてIOが発生していなければ、いいことです • 全てのリソースを最大限まで使えたら完璧なチューニング • つまり – CPU使用率100% – メモリ使用率100% – ディスクI/O使用率100% – NW使用率100% を同時に見対している状態 9 考え方の整理はこの本がおすすめ
10.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 解くべき問題の明確化 10
11.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 本当にMongoDBが遅いのか? • 「画面の応答が遅い」「アプリの実行時間がながい」 →本当にMongoDBが遅いんですか? • ミドルウェアのログから各レイヤでの処理時間を計測 – 大多数のケースで、これが整理できていない 11 ブラウザ Webアプリ MongoDB t0 t1 t2 t3 t4 t5 t6 本当にココ が遅いの か?
12.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved MongoDBの何が遅いのか • 何のクエリが遅いのか? – 読み取り、書き込み、集計 – 可能であればクエリを特定する • 何の指標が遅いのか? – レスポンスタイムが遅い • スロークエリログを見てクエリ応答時間をみる • プロファイラを有効にしてクエリの情報を見る – スループットが低い • mongostatを見て、単位時間あたりの処理量をみる • mongotopを見て、コレクションごとの処理量をみる 12
13.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 遅い箇所の調べ方 • スロークエリログ – 設定ファイルで起動前に指定する – デフォルトで100msを超えるクエリは、ログに出力される • プロファイラ – 起動後にMongoShellなどで接続して一時的にプロファイラを有効 にする 13 2015-07-10T04:09:01.113+0900 I COMMAND [conn1] command test.$cmd command: insert { insert: "mycol", documents: [ { _id: ObjectId('559ec6cd959e8f181ae68153'), name: "watanabe" } ], ordered: true } keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 2 } } } 120ms #プロファイラを有効にする > db.setProfilingLevel(1) { "was" : 0, "slowms" : 100, "ok" : 1 } #中身を見る > db.system.profile.find()
14.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 遅い箇所の調べ方 • mongostatコマンド • mongotopコマンド 14 $./bin/mongostat connected to: 127.0.0.1 insert query update delete getmore command flushes mapped vsize res ... 40 *0 *0 *0 0 1|0 1 12g 24.4g 51m ... 30 *0 *0 *0 0 1|0 0 12g 24.4g 52m ... 32 *0 *0 *0 0 1|0 0 12g 24.4g 53m ... $ ./bin/mongotop ns total read write 2015-07-10T04:56:52+09:00 mydb.mycol 6ms 6ms 0ms admin.system.roles 0ms 0ms 0ms admin.system.version 0ms 0ms 0ms ns total read write 2015-07-10T04:56:53+09:00 mydb.mycol 44ms 44ms 0ms admin.system.roles 0ms 0ms 0ms admin.system.version 0ms 0ms 0ms
15.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 遅い箇所の調べ方 • MongoDB CloudManager(旧OpsManager, MMS)を使って も良い – あらかじめMongoDBに特化したメトリックがとられる – 監視項目を設計しなくて良い 15
16.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 16
17.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 • 結論は2種類 – ボトルネックが有る or – ボトルネックが無い • ボトルネックが有る – CPU 1core張り付き、高ロードアベレージ→1.CPUボトルネック – メモリ空き容量0、ディスクIO頻発→2.IOボトルネック – ネットワーク流量 逼迫(80%超え) →3.NWボトルネック • ボトルネックがない – MongoDBに本気を出させることが出来ていない→4.処理の非効率 17
18.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 1.CPUボトルネック • 概要 – Aggregationや算術演算で、CPUを使う処理が多い場合にボトルネックになるこ とがある。 – CPUボトルネックはIOやネットワークにボトルネックがない場合がおおいため、 どちらかといえば健全な状態。 • チェック方法 – 1コアに注目したとき、使用率のuserとsysの合計が100%になっていないか • 全体のCPU使用率50%、25%、12.5%は要注意 – 50%→2core中1つが100% – 25%→4core中1つが100% – 12.5%→8core中1つが100% • 例 ) $ dstat -c -C 0,1,2,3,total – ロードアベレージはコア数以上になっていないか • 解消方法 – 応答性能向上 • マルチスレッドで動作する演算ならばコア数を上げる • そうでないならCPUクロック数を上げる – スループット向上 • コア数を上げる 18
19.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 2.ネットワークボトルネック • 概要 – アプリケーションに対してMongoDBが大量のデータを返す場合に 多い。 – 他には、レプリケーションのoplog転送量が想定以上に肥大化し、 ネットワークを圧迫している場合もある • チェック方法 – mongostatやOSのdstatコマンドにより、ネットワークの流量を監 視し、ネットワークのキャパシティ(1Gbit, 10GBit等)に対して流 れている流量が限界に達していないか? – 1Gbit/sの設定であれば800Mbit/sあたりで限界 • 解消方法 – ネットワークを太くする – 射影してアプリケーションで受け取るデータを減らす – oplogが肥大化が原因の場合は、肥大化を引き起こすオペレーショ ンに注意する • multi updateやremove、配列の$popや$pullなど 詳細は https://enterprisezine.jp/dbonline/detail/8095 19
20.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 3.IOボトルネック • 概要 – メモリ上にデータがなく、ディスクにデータを読みに行くことが頻発 すると、ディスクはメモリに対して100倍程度遅いため、全体として処 理速度が低下する。 – MongoDB(というかDB全般)では大半がこのケース • チェック方法 – OSのiostatコマンドで、 avgqusz, await, %util が高い。 rMB/s、 wMB/sがいつもより多い。CPUのiowaitが多い – キャッシュが溢れている • MMAPv1の場合、mongostatのページフォルトが多い • WiredTigerの場合、キャッシュへの読み込み累積値(bytes read into cache)が物理メモリ量を超えて増え続けている • 解消方法 – 次ページで説明 20
21.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 3.IOボトルネック - 解消方法 1. インデックス – RDBと同じB-Treeでインデックスがあるので、同じ考え方でインデックスを設 計すれば良い – 実行計画の見方 • db.mycol.find().explain() →実行はしないで計画を表示 • db.mycol.find().explain("executionStats") →実際に実行する 2. メモリキャッシュ – メモリを駆使してIOボトルネックを解消するには MongoDBのアーキテクチャの理解が必須 – ストレージエンジンによって全く違う • MMAPv1 : メモリ管理をOSまかせ • WiredTiger : MongoDBが買収した最先端のストレージ – →後半でガッツリ説明 21
22.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 根本原因の特定 4. 処理の非効率 • 書き込みが遅い – ロック開放待ちになっている(MMAP限定) – バッチインサートしていない – Write Concernの値が必要以上に大きい – WiredTigerの場合は同時に実行できるクエリ数にそれぞれ128 の制限(Ticketsという)があり、それに引っかかっていないか • db.serverStatus().wiredTiger.concurrentTransactions • 読み込みが遅い – フェッチが細かすぎる – 同時実行 – 同時実行クエリ数制限 22
23.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved IOボトルネックの解消 MMAPv1の場合 23
24.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 読み込み時の動き(MMAP) • 起動時に、mongodは、OSに対して、 データベースファイルをメモリにmapするように依頼する – システムコールmmap()を実行 • 起動直後はメモリは空 24 doc1 doc3index doc2 ディスク メモリ mongodプロセス OSが管理 ブロック データベースファイル mmap( )
25.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 読み込み時の動き(MMAP) • mongodがdoc1を読もうとすると – mongodは、OSに対して、ブロックの取得を依頼 – OSは、メモリ上にないので、ディスクから読む(=遅い) • ページフォルト発生 • doc1と関連するindexのブロックだけが読み込まれる 25 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス index
26.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 読み込み時の動き(MMAP) • doc1をもう一度読む – mogodは、OSに対して、ブロックの取得を依頼 – OSは、メモリにあるので、メモリから返す応答する(=速い) 26 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス index
27.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 読み込み時の動き(MMAP) • doc2を読むと – indexはメモリにあるが、doc2はメモリにないので、ディスク から読む(遅い) 27 doc1 doc3index doc2 ディスク メモリ doc1 mongodプロセス doc2index
28.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 読み込み時の動き(MMAP) • doc3を読むと – doc3はメモリにないので、ディスクから読む – 空きがないので、最もアクセス頻度の低いブロックを追い出す(ス ワップアウト) 28 doc1 doc3index doc2 ディスク メモリ mongodプロセス index doc3
29.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved MMAPで、IOネックで、読み込みが遅いときの原因候補 • インデックス – インデックスが使われていない – インデックスが有効ではない • フルスキャンの方が効率が良い • hint()の利用を検討 • キャッシュ – 起動直後でキャッシュが空 – ワーキングセット(インデックスと使うデータ)がメモリに対して大す ぎる – OSにメモリの空きがなく、mongodがメモリをもらえていない – 射影してもメモリにはドキュメント全体がのるが、その動きを知らない • db.mycol.find({},{"name":1}) としてもname以外のデータもメモリに 乗る – ブロックサイズがドキュメントに対して大きすぎて無駄が多い 29 doc1 無駄
30.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 書き込み時の動き(MMAP)ジャーナルなし • update doc1を実行すると – mongodは、OSに対して、データベース単位のロックを依頼して更新 • MongoDB 3.0ではコレクションレベルでロック – 他のスレッドからの書き込みは待たされる(=遅くなる) – メモリ上にindexとdoc1があればメモリ上で更新は完結。なければIO発生 – 非同期でディスクに書き戻し(60秒に一回) • クラッシュすると最悪60秒間ロストする&データベースファイルが破損する 30 doc1 doc3index doc2 ディスク メモリmongodプロセス doc2index' スレッド スレッド 書き込みを待たされる2.ロック・ doc1とindexを更 新 × 1.アプリからクエリ4.アプリに返却 ロック開放 5.60秒に1回ディスクに書き戻し fsync() doc1'
31.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 書き込み時の動き(MMAP)ジャーナルあり • update doc1 – ジャーナルファイルに更新内容を記載 • クラッシュしても100ms以内の変更は保持 • クラッシュしてもデータ破損自動修復 31 doc1 doc3index doc2 ディスク メモリmongodプロセス doc2 スレッド 2.ロックを取得 更新内容を追記 ジャーナル ジャーナル 5.100msに1回flash (j:trueなら即時) 4.アプリに返却 ロックを開放 1.アプリからクエリ 3. doc1とindexを 更新 6.60秒に1回ディス クに書き戻し doc1'index'
32.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved MMAPで、IOネックで、書き込みが遅いときの原因候補 • インデックス – インデックスがある • キャッシュ – 更新するドキュメント・インデックスがメモリに無い – ジャーナルとデータを同じディスクい書いている – 全てのデータベースが同じディスクに書いている – MongoDBのログをデータと同じディスクに書いている – Write concertnで j:trueになっていてジャーナルの物理書き込みを待って いる – ドキュメントのサイズが大きくなり、物理移動が発生している • 肥大化が起こると、そのコレクションでは、次からドキュメントサイズに余裕を 持って物理領域を取るようになる→Padding factorの増加 – データ移動が頻発し、データファイルがフラグメンテーションして、必要 以上にメモリを利用しなくてはならない 32 doc1 doc3index doc2 doc3index doc2 doc1' doc1index doc2 doc3
33.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved IOボトルネックの解消 WiredTigerの場合 33
34.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved WiredTigerの基本 • WiredTigerとは – MongoDB,Incが買収したストレージ – MMAPv1を差し替えることができる • MMAPv1との違い – OS任せだったメモリキャッシュを、ある程度制御するようになっ た – 更新は、その場(in place)ではなく、新しいバージョンのドキュメ ントを挿入して、ポインタを張り替えようになった(MVCC,CAS) • ロックが無くなった(事実上ドキュメントレベルロックと同じ) • データファイルのフラグメンテーションがなくなった • データの肥大化による移動がなくなった • 裏で、古いバージョンをマージする動作(eviction)をするようになった • これらにより、複数スレッドでマルチコアを有効に使って、スルー プットをあげられるようになった – インデックスとデータが別ファイルになった – データの圧縮ができるようになった(メモリ量は圧縮できない) 34
35.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • 起動直後はWiredTigerキャッシュは空 35 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド dirtyページ cleanページ on diskページ root
36.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • 読み込むとツリーが形成される • ツリーのリーフはディスクのページ毎に読み込まれている • 以下の例ではdoc1を読んでいるので、indexとdocが含まれるページがキャッシュにのる 36 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root dirtyページ cleanページ on diskページ
37.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • さらにdoc2やdoc3を読むと、キャッシュにのる 37 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 dirtyページ cleanページ on diskページ
38.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • ここでトランザクションtx1でdoc1をdoc1'に更新しようとする (説明を簡単にするため、index更新は図から省略) – これは新しいツリーをつくる動きになる • それとは別に、メモリ上のジャーナルに更新内容を書き込む – 50ms毎にディスクにSnappyで圧縮されて永続化される 38 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx1 tx1 tdoc1→doc1' ジャーナル ジャーナル doc1→doc1'
39.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • tx1が終わる前に、doc1の読み込みトランザクションtx2が動き出 すと、古いドキュメントが見える 39 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx1 tx2 tx2 tx1 tdoc1→doc1' doc1→doc1' ジャーナル
40.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • tx1がcommitした後に、tx3がdoc1を読みに行くと、 新しいdoc1' が見える 40 doc1 doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ tx3 tx2 tx1 tx3 t doc1→doc1' ジャーナル
41.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • 前回のチェックポイントから60秒経過するか、 ジャーナルが2GBを超えると、チェックポイントになる • Evictionスレッドがcleanなページとdirtyなページをマージしてディス クへ書き込む 41 doc1' doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド doc1index root doc 3 doc2 Evictionスレッド doc1’ root(tx1) dirtyページ cleanページ on diskページ doc1→doc1' ジャーナル
42.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved mongodプロセス WiredTigerキャッシュ WiredTigerの動き(たぶん正しい) • チェックポイントが終わると、古いツリーは消されて、 キャッシュとディスクが同期する • ジャーナルは空になる 42 doc1' doc 3index ディスク メモリ doc2 Readスレッド Writeスレッド index doc 3 doc2 doc1’ root(tx1) dirtyページ cleanページ on diskページ ジャーナル (空)
43.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved WiredTigerで、IOネックで、書き込みが遅いときの原因候補 • インデックス – インデックスがある • キャッシュ – 更新するドキュメント・インデックスがメモリに無い – ジャーナルとデータを同じディスクい書いている – 全てのデータベースが同じディスクに書いている – MongoDBのログをデータと同じディスクに書いている – Write concertnで j:trueになっていてジャーナルの物理書き込みを 待っている – ドキュメントのサイズが大きくなり、物理移動が発生している – データ移動が頻発し、データファイルがフラグメンテーションして、 必要以上にメモリを圧迫している 43
44.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved WiredTigerで、IOネックで、読み込みが遅いときの原因候補 • インデックス – インデックスが使われていない – インデックスが有効ではない • キャッシュ – 起動直後でキャッシュが空 – ワーキングセット(インデックスと使うデータ)がメモリに対して 大すぎる • メモリ上は圧縮されないので注意! – 射影してもメモリにはドキュメント全体がのるが、その動きを知ら ない – ブロックサイズがドキュメントに対して大きすぎて無駄が多い – OSにメモリの空きがなく、mongodがメモリをもらえていない – WiredTigerだからおそい。MMAPv1よりやることが多い。 – WiredTigerのキャッシュを割り当てすぎてファイルキャッシュに使 えない(次ページで詳細) 44
45.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved WiredTigerキャッシュにメモリを割り当てすぎることによるデメリット – mongodそのものでOOMになる可能性がある – リードが多い場合は、Wiredキャッシュよりも、データが圧縮されている ファイルキャッシュに多くのドキュメントを載せたほうが効率が良い事がある 45 mongodプロセス WiredTigerキャッシュ ディスク メモリ mongodそのものがつかうメモリ Aggregation, Sort, 等 OS OSのファイルシステムキャッシュ doc1 doc1 doc1 圧縮 圧縮 非圧縮 mongodの実メモリ 量 設定できるのは ココだけ 空きメモリから 自動的に確保 2017/2/20更新: 「MongoDBのファイルキャッシュ」は存在しないため図から削 除
46.
Copyright ⓒ2016 CREATIONLINE,
INC. All Rights Reserved 参考にした資料 • ちょっと古い公式説明資料。だいたい同じスライド – http://www.slideshare.net/mongodb/mongo-db- wiredtigerwebinar?ref=https%3A%2F%2Fwww.mongodb.co m%2Fpresentations%2Fwebinar-a-technical-introduction-to- wiredtiger – http://www.slideshare.net/NorbertoLeite/mongodb- wiredtiger-internals – https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx ?id=9a55027f-2b6c-48f4-86f6-73cc167619d0 • 新しい公式セミナ。WiredTigerで使っている様々な工夫を詳細に 説明している。 – https://www.mongodb.com/presentations/mongodb-europe- 2016-building-wiredtiger • ブログ。WiredTigerのstatの見方や、パフォーマンスチューニング について解説している – http://www.developer.com/db/tips-for-mongodb-wiredtiger- performance-tuning.html 46
Download now