DBエンジニアの徒然日記 -3ページ目

OSリソース上の問題

今回はパフォーマンス劣化問題の続きとして、OSリソース上の問題についてまとめてみることにします。


前回までの処理経路云々に関する問題は基本的には開発者側、アプリケーション側の問題であり、データベースを含めたアプリケーションというレベルでの問題でした。


これに対してOS上の問題というのは、そのアプリケーションが稼動するためのプラットフォームに問題があるケースを指します。


簡単な例としては、


・メモリ不足

・メモリリーク

・CPU不足

・DISK I/O量増大


ぐらいが該当するでしょうか。



ここからは僕の個人的な見解ですが、これらの解決へのアプローチは以下になるかと思います。



・メモリ不足


定期的にアプリケーション、OS、RDBMSソフトウェアが使うメモリ領域を監視する。Unixであればpsコマンドや各OS毎に用意されている詳細を取得するコマンド(AIXならsvmon)で、Windowsならパフォーマンスモニタで。

普通にこれで監視するだけで、どの程度のメモリが必要なのかは判別可能なはずです。



・メモリリーク


これはなかなか気付きにくい事象ですが、基本的にはこちらもpsコマンドとかで定常取得するしかないでしょう。vmstatでも情報取得しておけば、リーク時のSwapの動きが見れたり、CPUが遊んでるのがわかったりはするかもしれませんね。



・CPU不足


これはvmstatのRunqueueを見ればわかるでしょう。あと使用率と。これらを見て、CPUがかなり限界まで回っていて、Runqueueも溜まっている場合は、そのCPU数では性能的に無理があるということです。

ただしvmstatの見方については、Unix毎に違ったりしますので、OSベンダーへ確認はしたほうが良いと思います。



・DISK I/O量増大


これはSQLがバカなケースが多いでしょうか。まずは大量にブロックを浪費するような処理がないかを確認した方が良いでしょう。各SQLで特に問題がないのであれば、処理量・数が現行のDISKでは持ちこたえられない可能性があります。この場合はDISK増設や回転数の良いDISKへの置き換え、FibreChannelへの変更等の手立てを考えた方が良いでしょう。



かなりざっくり書きましたけど、だいたい上記アプローチで解決に至るケースが多いです。

まぁ細かい点を言い出すと、キリがありませんが。


いずれにせよ、OSリソースについては定常監視しておくこと、これに尽きるのではないでしょうか。

遠隔地コピー

最近、流行ってます?


高速コピー機能なるものは数年前からよく見かけるようになりましたが、遠隔地間の高速コピー機能は高価であり、何よりインフラが相当太い必要があったかと思うわけですが、好景気とインフラが整ってきたことが相まったことで、流行ってきてるのでしょうか。


世の中的な流行度合いが気になる今日この頃。


どうなんでしょうかねぇ。


まぁめちゃめちゃ便利であることは間違いありませんけどね。


根本的な事

ご無沙汰しています。slidermanです。

最近少し激務で更新が遅れており、申し訳ありません。


そんな働きまくっている中で、ふと思う事があります。



DBエンジニアの仕事の範囲って何??



昔は比較的範囲が狭く、データベースを中心に面倒を見ている事が多かったんですが、最近はデータベースという範囲からネットワーク、さらには運用管理、アプリケーション云々と、範囲が広がってきているように思われます。

(まぁボクがそうなってきているだけなのかもしれませんが・・・)


幅広い分野に対して面倒を見れる人材が減ってきているような気がするのは気のせいでしょうか。


逆に言えば、DBエンジニアという言い方や職種も今後は減っていき、もう少し広範にシステムを見れる人たちが生き残っていくのではないか、


そういう気がしてなりません。


では、何を身につけていくべきなのか、


何をすればこの業界で生き残っていけるのか。



未だ答えは見えません。


が、「仕事の範囲を広げていく」のは1つの答えになりえるのではないかと思っています。



とりあえずSyn/Synackの勉強でもしようかな。