/dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど）
前エントリーから一部の内容を分離して追加記事にしてみました。以下実施したメモリ増設の効果について。 ここ数ヶ月、自宅サーバの負荷がだんだんと上昇してきていて、そろそろ１台で高速にさばききる限界に近づいてきた感があったり。ここ数週間のロードアベレージはこんな感じ。グラフは× 100 の値になってます。CPU のコアが２個なんで、200 までは OK ということでまだ処理しきれているわけではあります。ちなみに mrtg グラフは瞬間値を示しているわけではなく平均値なので瞬間的にはもっと負荷が高いときとかあります。 でも月次処理が走るともっさり感満点。 ※緑：１分平均 ／ 青：１５分平均 実は CPU の処理速度が追いついていないと言うより I/O 周りがボトルネックになっています。 ※緑：読取ブロック数 ／ 青：書込ブロック数 ということで、メモリを２GBプラスして、合計 4GB にして参照系
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
「mixiの画像ファイルは1日に23Gバイトずつ増える」---バタラ・ケスマCTO
日本最大のソーシャル・ネットワーキング・サービス（SNS）「mixi」を運営するミクシィのバタラ・ケスマCTO（最高技術責任者）は8月23日，都内で講演し，mixi内の画像ファイルは合計で9Tバイトを超えていると説明した。さらに「1日に23Gバイトくらい増えている」（バタラCTO）という。 バタラCTOによるとmixi内の画像ファイルは2種類に分かれる。つまり，(1)プロフィールの写真やコミュニティのロゴのように頻繁にアクセスされる画像と，(2)日記やアルバムの写真のようにアクセス頻度の少ないものだ。(1)はファイル数が少なく，サイズも合計で数百Gバイトしかないのに対し，(2)はファイル数が多く，合計で数Tバイトに及ぶという特徴がある。 そこでmixiは(1)の画像ファイルに対しては「キャッシュのヒット率が非常に良いので普通にキャッシュすれば良い」（バタラCTO）という方針を取る。キャッシ
サーバやPCのボトルネック箇所の簡単な見分け方(Linux編)：佐野裕のサーバ管理者日記：ITpro
前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
