  |
はてなキーワード: CPU使用率とは
恥ずかしすぎてハンドルネームでやってる自分のブログにすら書けず、かと言ってどこかに吐き出したくはあったのでここに書いておく。
見た人は存分に笑い飛ばして欲しい。
先週、趣味で立てたVPSサーバー(CentOS 6.5)のCPU使用率が、気付くまでの9時間ずっと100%になっていた。
作動中のプロセスを見ると、2つのperlプロセスがその原因であることが分かった。
そのプロセスはユーザー「postgres」によって実行されたプロセスだった。
postgresは、PostgreSQLをインストールすると勝手に作られるユーザーだ。
先日自分でPostgreSQL9.4をインストールしたので、このユーザーの存在自体は問題無い。
その時このpostgresに、「postgres」という簡素なパスワードを、passwdコマンドで設定した。
「まぁ無いよりはマシなんじゃね？サーバー内でしか使わないユーザーだからハッキングの心配とかないしどうでも良いけど〜。」
と言ってたと思う。
その程度の認識だった。
これにより下記コマンドでpostgresとしてサーバーに入れてしまう状態になっていた。
$ ssh postgres@my.server.address.com
実行するとパスワードを求められるが、もちろんそれは前述のパスワード「postgres」だ。
それまではパスワードを設定していなかったので逆に助かっていた。
パスワードが設定されていないユーザーにはsshでは入れないからだ。
「もちろん」というが、それまではユーザーのパスワードがsshで入る時のパスワードになることを知らなかった。
そしてそれだけで接続可能になる可能性があることを知らなかった。
sshサーバーの設定はひと通り、自分が使っているVPSサービスがやってくれており、多分大丈夫だろうとそのまま使っていたからだ。
それでハッキングされ、そいつに謎のperlスクリプトを走らされていた。
具体的なスクリプトファイルや.bash_historyは消されていたようで、どんなものを走らせられていたのかよく分からない。
ハッキングであることを知ったのは、/var/log/secure を見たからだが、そもそもこの自体に陥るまで /var/log/secure の存在とその役割を知らなかった。
「ポスグレ(PostgreSQL)がなんかバグったわ〜でも原因がよく分からんわ〜ヒマだしハッキングの可能性も考えとくか〜でも絶対ポスグレがバグったんだわ〜」
でググって初めて知ったぐらいだ。
それで見たらパスワード設定してから9日間でそれぞれ別の端末23件から不正アクセスを受けていたことが分かった。
VPSサービスのコントロールパネルを見ると、その内の1件が侵入した3分後にCPU100%現象が始まったので、十中八九そいつの仕業だろう。
それ以外の連中が何をやったのかは分からない。
分からないのでOSを再インストールした。DoS攻撃だったらあとで攻撃先に訴えられるかもしれないので、全データを家のパソコンにDLする事で証拠（？）を保存してから。
/etc/ssh/sshd_config には、sshサーバーの設定が書かれている。
その中のPasswordAuthenticationをnoにし、公開鍵暗号方式による認証のみ受け付けるようにした。
他になんかやることとかある？おしえてぴょーん
先日ニコニコ動画がリニューアルされ、ビットレートや解像度などの制限が撤廃された。
http://av.watch.impress.co.jp/docs/news/20091028_324929.html
それを受けて早速「画質の限界」に挑戦する動画が上げられ始めている。たかだか1分から2分程度の動画で容量制限(100MB)ギリギリ一杯まで使った動画である。
もし見たければ、さしあたり「高画質再アップ祭り(9)」でタグ検索をしてみると良いだろう。中にはビットレートが40Mbpsという冗談みたいなものもある。これはBlu-ray映像の上限値に匹敵するものだ。そんな動画をいくつか見ていて気になるのが、動画内でのコメントだ。
「カクカクする」
「コメントを非表示にすればなんとか見られる」
「CPU使用率100%」
「重すぎて見られない」
こんなコメントをよく目にするようになった。マルチコアCPUと十分なメモリを搭載したPCであれば再生にさほどの負荷を感じないはずだが、こういったコメントが目立つあたり、古いPC(それでもOSや一般的なアプリを動作させるには十分すぎる性能だとは思うが)で見ている人の多さを実感させられる。前述の40Mbpsの動画は極端にしても、今後は数Mbps程度の動画が増える事だろう。それに伴い動画の容量も増えていくだろうから、有料会員(時間帯によっては低画質でしか再生出来ない無料会員と違って常時高画質で再生される)の付加価値も高まるだろう。少しばかり古いPCを使っている無料会員の今後の動きが気になる。
http://anond.hatelabo.jp/20091030202541
あーネットブックか。
外出先で気軽にニコ動が見たいという動機で買った人は言いたくなるかもね。
(http://www.kev009.com/wp/2008/11/on-file-systems/)
訳した。分からなかったところは英語のまま。ファイルシステムについて完全な素人なので変な所があるかも。
ファイルシステムはOSの重要な要素だが最近ではあまり関心を払われていない。ビットが入ってきてビットがでていく……デスクトップシステムにとっては、たいてい十分に働いてくれる……ただし、電源が落ちるまでは。しかし、そんな状況ですら近頃ではあまり困ったことにはならない。
Linuxのファイルシステムの分野には競合製品が多い。ext2が長い間標準とされてきたが、2001年辺りから他の選択肢も主流となった。あまり歴史に深入りせずに要約すると(順番は適当)、ext2が進化してext3となり、ジャーナリング機能が付いた。ReiserFSがリリースされた。SGIはXFSを移植した。IBMはJFSを移植した。
いくつかの理由があって(主に政治的な理由で)ext3がLinuxのデファクトのファイルシステムとなった。
私が古典的ファイルシステムと呼ぶとき、基本的にいつも同じ概念を指している。つまり古典的なUnixレイアウトのファイルシステムにジャーナリング機能を追加したものだ。ここに述べるのは、それら古典的ファイルシステムのハイライトである。
これは後知恵だが、JFSやXFSが牽引力を持たずに、ext3が人々を古典的時代に停滞させたのは一種の悲劇だった。しかしながらext3は信頼性を証明し、きちんと動くように一貫として保守されてもいる。
2005年にSunはZFSという爆弾をリリースした。ZFSは私が次世代ファイルシステムと呼ぶ時代への案内人である。
ハードディスクが大きくなるにつれて、バックアップの戦略、完全性(integrity)の検証、巨大なファイルのサポートは前より遥かに重要になってきている。
ここあげるファイルシステムは古典的なVFS lineを曖昧にしたりLVMとRAIDを強固な結合することによって管理を楽にする事を目的としている。
ダメなハードウェアで起きる静かな(観測されない)データの破損も心配の種である。これに対抗するために、次世代のファイルシステムはチェックサムを供えている。
いろんな意味でLinuxのコミュニティーは完全に油断しきっており、多くの開発者はZFSがリリースされるまで次世代ファイルシステムについて真剣に考えてこなかった。Reiser4はいくつかの新しいアイデアを持っていてキラーファイルシステムとなろうとしたが、Hans Reiserは、他のカーネル開発者との著しく酷い関係を楽しんでいたのだった。ただ幸運な事に、いまではいくつかの、より先進的なファイルシステムが登場しようとしている。
kernel 2.6.28と一緒にext4がリリースされるが、BtrfsやTuxs3が安定するのを待った方がよい。Btrfsの開発陣は短距離走開発を行っているので、Linuxのカーネルの開発サイクルに次か、あるいはその次で取り込まれると思われる。
SSDが普及するのは明白だ。理論的に速度の面で磁気ストレージより圧倒的に早く、現実にも既に書き込み速度が追い付きはじめている。最新のIntelのランダムアクセスやIOPSは非常に印象的である。Btrfsは当初からSSDへの最適化を取りいれようとしている。しかし、これらの新しいデバイスは、更に速度の早い新しいファイルシステムを生むだろう。
私自身の考えでは、ウェアレベリングやFATエミュレーションがSSDの性能を押し止めているため、 新たなファイルシステムが登場すればパフォーマンスを改善できるだろう。
はてなブックマーク登録時のタグ自動補完が重いという話が出ている。
うちもunDonut＋ブックマークレットで登録しているが、確かに重い。
候補一覧などはそれほどでもないが、毎回JavaScript初期化のためCPU使用率100%のまま5秒近く待たされる。
タグ数400強でこれなのだから、1000近くならそりゃ重くなるだろう。
http://hatena.g.hatena.ne.jp/hatenabookmark/20070406/1175838568
先日のサーバーメンテナンスでシステムリソースに余裕を持たせることができた点、1,000 件では現状にそぐわない点などを考慮いたしまして 5,000 件まで引き上げるよう変更を行いました。
現在は5000件までタグを表示できるらしいが、タグ数に比例して初期化に時間がかかる現状では地獄が待っているだけだ。
