ext4 ファイルシステムのオーバーヘッドを厳密に理解する - とあるSIerの憂鬱
ファイルシステムを作成すると、ファイルシステム自体の管理領域などのため、ファイルシステムを作成するデバイス・ボリュームの容量を100%使えるようにはならない。 では何パーセントが減ってしまうのか。10%あれば大丈夫なのか、3%程度でもよいのか、厳密には決まらないのか、そんな疑問・不安を取り除くために検証および論理的な裏取りを行った。 検証環境は CentOS 6.4 (x86_64) で、ファイルシステムは ext4 である。なお、ブロックサイズは 4KB を前提にする。CentOS 7 (RHEL 7) でも考え方は同じだが、計算の元になる基礎値に差があるため注意が必要(「その他」にて触れる)。 検証結果 128M, 256M, 512M, 1024M, 1.5G, 2G, ・・・ と20GまでのLVを作成し、実際にファイルシステムを作成。マウントした際の df -k の Availab
オンラインREDOログ設計 - とあるSIerの憂鬱
オンラインREDOログ(以降は単にREDOログ)の設計について考えた事、Oracleがマニュアルで示している設計方針をメモ。 REDOログ設計で決めること REDOログ1ファイルのサイズ REDOロググループの数 REDOロググループ内のメンバー数 REDOログの物理配置 考える観点 性能 信頼性 コスト Oracleがマニュアルで示している設計方針 『Oracle® Database管理者ガイド 11g リリース2 (11.2) 12.REDOログ管理』 『Oracle® Databaseパフォーマンス・チューニング・ガイド 11gリリース2(11.2) 4.1.3 REDOログ・ファイルのサイズ指定』 REDOロググループ内のメンバー数 あまり悩まずに決まる設計部分。 1個か2個以上か 1個 2個以上 性能 1個にのみ書くため最もI/O量は少なく速い。アーカイブ速度は理論的には2個以上
STORAGE句でのエクステント関連の設定 - とあるSIerの憂鬱
ディクショナリ管理とローカル管理で意味合いが異なるもの、そもそもローカル管理では使われない・無視されるものがありわかりにくい。マニュアル(SQLリファレンス)の記載も今一煮え切らない。ということで検証してみる。 STORAGE句で指定するエクステント関連の設定項目 INITIAL NEXT MINEXTENTS MAXEXTENS (ローカル管理では無視される。エクステント数は事実上無制限) MAXSIZE PCTINCREASE 今回得た設計上の指針 (ローカル管理が大前提) STORAGE句で指定するエクステント関連の設定項目で検討価値があるのは2つ INITIAL MAXSIZE MAXSIZE MAXSIZEはそのままの意味。テーブルにサイズ上限を設定したければ設定する。明らかに拡張しないマスタテーブルなどに用途があるかもしれないが、あえて制約をしたいという判断があるかは疑問。頭の
NTP設定 - とあるSIerの憂鬱
環境 RHEL5 ( ntp-4.2.2p1 ) RHEL6 ( ntp-4.2.4p8 ) NTPは結構微妙な修正を入れてくるのでバージョンが異なる場合は注意が必要。 manが当該バージョンの情報源としてはまず優先。 最近の変更 RHEL6ではRHEL5で /etc/init.d/ntpd のみで行っていたことを /etc/init.d/ntpdate と /etc/init.d/ntpd に分離している。 ntpd起動前のntpdate実行について分離している。ntpdを使うのであればntpdateも同時に有効にするべき(ntpdate実行を避けたい場合以外)。 設計 何もよりも先に 『参考』にあげた富士通の『Linuxユーザーズマニュアル RHEL6編』がNTPの説明として詳しい・わかりやすい。まずはこれを読む。 NTPサーバの階層設計 NTPを使う目的は『正しい時刻の維持』と『時刻
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
