RDBMSやJVMは起動したら、OSからまとまった量のヒープ領域をmallocしてキープする。
これらのミドルウェアは、多めのヒープ領域を確保して、その中から必要な分を切り出してサブコンポーネントやプログラムにアサインする。
なので、OSからは、これらのミドルウェアが実際どれだけメモリを使用していて、枯渇までどのくらい余裕があるのか把握できない。
なので、RDBMSやサーブレットコンテナのヒープ使用率などは、これらプロダクト側で用意されたツールを使って状態確認や監視をしないといけない。
１．PostgreSQL
postgreSQL その1～7（自ブログ）
DB2はじめの1歩～13歩（自ブログ）
※PostgreSQLのトランザクションログは時刻逆行で壊れないらしい？ →要調査
※PostgreSQLのオンラインバックアップはテーブルロックではなく、トランザクションログからSQLを再実行する方式なのでテーブル間の不整合は起こらないらしい？ →要調査
■ディスク上のオブジェクト
・システム寄りのオブジェクト
- バッファやキャッシュ
- テンポラリファイル
- トランザクションログ
- その他管理データを含むファイル類
・データ寄りのオブジェクト
- テーブル
- インデックス
■メモリ上のオブジェクト
・バッファ、キャッシュ
・スタック
・その他のヒープ
・
■CPU負荷が高くなる処理
■ディスクIOが高くなる処理
■その他のリソース上の問題個所
・プロセス間通信
■リソース枯渇を引き起こす箇所
■データロストになりかねない箇所
・オンラインバックアップ
・HAクラスタのフェールオーバ/フェールバック
・表領域の破損
・バッファの枯渇
・トランザクションログの破損
・レプリケーションの失敗
・異常終了
■ダウンタイムを引き起こしかねない箇所
・ヒープの枯渇
・OS領域のメモリ枯渇からswapout
・処理の遅延
・異常終了
・ハング
■セキュリティインシデントになりそうな箇所
【方針】
データ構造と投げるSQLを設計してシングル構成DB2とWASでWebアプリと集計ジョブを作る
・PostgreSQL silver資格本全部やってみよう
・PostgreSQL gold資格本買ってやってみよう
・資格受けてみよう
・PostgreSQLだけじゃなくSQL、データ構造に関する共通の基礎を抑えよう
・他のRDBMSとの相違を理解しつつ、RDBMSに共通の一般的な知見を帰納しよう
・RDBを含めたDBに対する機能要件、非機能要件を調べてDBやデータ構造設計に対して知見を持とう
- いくつかの典型的なありがちの業務システムのRDB
- CMSのRDB
- 掲示板のRDB
- 勘定系のRDB
ミッションクリティカル。日中はオンライントランザクション処理、夜間はバッチ処理
- デジタルアーカイブのような画像や動画データを格納するデータベースの要件
- memcachedのような特定用途で超高速DB
- 大規模なDB
- クラウドで利用される、スケーラビリティ、高速性、冗長性を備えたストレージ
- 検索エンジンに使われるインデックスの特徴
- OSのあちこちで使われていたBerkeley DBとは？
- 監視マネージャのRDBが備えるべき特徴
- ジョブマネージャのRDBが備えるべき特徴
- そもそもテキストファイル一枚のDBの限界。あるいはそれで充分なケース
- データウェアハウス
- ビッグデータを格納するDB
・RDB以外のDBについても考えてDBに共通の一般的な知見を帰納しよう
- NoSQL
グラフ型DBとは？
KVSとは？
Radis
mongoDBとは？
- ファイルシステム
OS標準のファイルシステムの機能だけでどこまで、信頼性、高速性、整合性などを持たせる
ことができるか？
- 分散ストレージ
Hadoop
GlusterFS
Spark
hadoopより後発でイケてるらしい
- ディレクトリ
LDAP
- solrのインデックス
- その他
２．tomcat8
■ディスク上のオブジェクト
・javaプログラム
・
■メモリ上のオブジェクト
■CPU負荷が高くなる処理
■ディスクIOが高くなる処理
■その他のリソース上の問題個所
・プロセス間通信
■リソース枯渇を引き起こす箇所
■データロストになりかねない箇所
・オンラインバックアップ
・HAクラスタのフェールオーバ/フェールバック
・表領域の破損
・バッファの枯渇
・負荷分散クラスタしてる場合の同期の失敗
・異常終了
・ハング
■ダウンタイムを引き起こしかねない箇所
・ヒープの枯渇
・OS領域のメモリ枯渇からswapout
・処理の遅延
・異常終了
・ハング
■セキュリティインシデントになりそうな箇所
・
■その他のリソース
・プロセス間通信