サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
iPhone 16e
kashi.way-nifty.com
PostgreSQLは他のRDBMSと比較したときにMVCCを採用しているがために、データベースが肥大化しやすい傾向があることは否めない。 ただし適切なタイミングでAUTO VACUUMが稼動していれば、爆発的な肥大化というのは基本的には起きないんじゃないかな、とは思うがそれでも肥大化してにっちもさっちもいかなくなる、ということは発生しうる。 "No space left on device"エラーが出力されると最悪だ。 基本的にはデータはpg_dataディレクトリ配下に保存されていることが多いだろう。 まずはこのディレクトリを含むデバイスの空き領域を確認する。 Linux/UNIX系であればdfコマンドを使って確認することが多いだろう。 しかしこのエラーが出たということは、pg_dataがあるディレクトリのマウントされている領域は空きがない＝パンクしている、ということなので、対策としては
最近（というほどでもないが）にわかにはやってる言葉に DevOpsがあるのだが、もともと少人数で回している部署だと自動的にDev(保守)Ops(運用)になっているケースも多くあるんじゃなかろうかと思う。 そう考えると私の知ってる多くの職場は（自然発生的に）DevOpsばかりのような気がする…… とはいえ、東証１部上場企業様などでは内部統制の縛りから、かなり真面目にDev部門とOps部門を分離しているのも事実である。 ただ、この分離は自発的な物ではなく内部統制（J-SOX）対応から発生しているため、なんとなくいびつな状態になっているケースもちらほら。 そうしたことを考えながらも実際にあったDevOpsが回らなかった事例を紹介してみる。 ◆開発チームからの引継ぎがない 既存システムの改修の場合でさえも不思議と発生するのだが、作るだけ作ってぽいっとされるパターン。 理由系としては 忙しくて引継ぎ
主としてLinuxをターゲットとして、サーバの状態を監視しないといけないことは多々ある。 アプリ開発部門なのにインフラのサイジングとか挙動とか見てる・・・DevOpsだ！（笑） まあそれはさておき、サーバの負荷状態を見る上ではCPUの利用状況を見るのは基本のキになる。 サーバの状況監視としては CPU使用状況 メモリ使用状況 ディスクIO状況 ネットワークトラフィック状況 あたりをまずは概観することとなる。 Windowsについてはタスクマネジャー最強、ということで今回のエントリーは対象外。 実際にはWindowsでもtasklistなどいくつか有用なCUIツールやロギング方法はあるのだが、まずはLinux系が対象である。 top 今回は上記のうちCPUについて着目するので、このコマンドについては次回と確認とする。 実際にはtopコマンドはCPUの状況だけではなく、メモリやプロセス動向など
連投でPostgreSQL関連のエントリー。 Autovacuumが実装されて以来、PostgreSQLについては定時VACUUMはあまり頭を悩まさなくて良いことになってきている。 実際、PostgreSQLのオフィシャル布告としてはAUTO推奨で、定期実行などはあまりすべきではない、という推奨状態になっている。 これは正しいのだが、すべてをデフォルトのまま利用していいかというと、必ずしもそういうわけではない。 AUTOVACUUMが稼動するのは次の条件に当てはまった場合。 -Dead Tupleがデータ領域の一定割合を超えた場合(autovacuum_vacuum_scale_factor) -Dead Tupleが各テーブルで定められた閾値を超えた場合(autovacuum_vacuum_threshold) AUTOVACUUMデーモンが一定間隔でこれらの状況を監視し、ロック競合が発
このページを最初にブックマークしてみませんか？
『kashi.way-nifty.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
