タグ

tuningとlinuxに関するkgbuのブックマーク (10)

  • Redesign of setroubleshooter.

    kgbu
    kgbu 2009/01/24
    setroubleshooterがメモリ食いなので、Fedora11(rawhide)に入れるべく修正をしたという話。全面的な書き換えではないようだ。
  • Linux チューニング - Ext3 のパフォーマンスを最大化させる

    じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで

    kgbu
    kgbu 2009/01/22
    atimeとかjournaling offとか、いろいろあるみたいだけど、怖くてできない私は小心者。
  • Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる

    Linux は fork で子プロセスを作成した場合、親の仮想メモリ空間の内容を子へコピーする必要があります。しかしまともに全空間をコピーしていたのでは fork のコストが高くなってしまいますし、子が親と同じようなプロセスとして動作し続ける場合は、内容の重複したページが多数できてしまい、効率がよくありません。 そこで、Linux の仮想メモリは、メモリ空間を舐めてコピーするのではなく、はじめは親子でメモリ領域を共有しておいて、書き込みがあった時点で、その書き込みのあったページだけを親子で個別に持つという仕組みでこの問題を回避します。Copy-On-Write (CoW) と呼ばれる戦略です。共有メモリページは、親子それぞれの仮想メモリ空間を同一の物理メモリにマッピングすることで実現されます。より詳しくは コピーオンライト - Wikipedia などを参照してください。 この CoW に

    Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる
    kgbu
    kgbu 2008/08/21
    /proc/PID/smapsで cleanな部分が親プロセスと共有、dirtyが増えてくると実メモリが別に割り当てられていく
  • TPRG: memo -

    _ 歯がゆい なんかトラブル続きだ。 RAID 壊れたマシン復旧 最初のセットアップにちょっとだけ関わっただけで、ずっと関知していなかったもの。 RAID の異常なのだけれど、調べてみれば、最初のディスクが死んだのは 去年の11月らしい。監視してなったのね……。 結局私に回ってくるんだったらセットアップに関わった時にエラーを 飛ばすものを色々しこんでおくんだった……。 DELL のサポートは非常に丁寧で、壊れている可能性のある場所を全部指摘して チェックするように言ってくれる……のはありがたいんだけどその分時間がわれる。 でもここでサボるとまた二の舞だし。 NFS overload? 他の仕事で NFS サーバの過負荷らしき現象。駄目だ、知識が足らない。 アイデアも出せない。そしてサーバルームに走ることも出来ない。 desire落ち この日記の動いているマシンがときどき落ちる。 といって

    kgbu
    kgbu 2008/07/26
    /proc/net/rpc/nfsd の最後の10個の数字の秘密が今明かされる。
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築

    連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「

    mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
  • ITmedia エンタープライズ:Linuxのパフォーマンスを改善する3つのTips (1/3)

    同じコンピュータでも、Linuxを走らせたときの方がWindows XPやVistaを走らせたときよりも性能は高くなる。しかしLinuxシステムはさらに高速化することも可能だ。稿では、Linuxシステムの性能を向上させるための、3つの異なるレベルで行う最適化の方法を紹介する。 同じコンピュータでも、Linuxを走らせたときの方がWindows XPやVistaを走らせたときよりも性能は高くなる。しかしLinuxシステムはさらに高速化することも可能だ。この記事では、Linuxシステムの性能を向上させるための、3つの異なるレベルで行う最適化の方法を紹介する。 あらゆる最適化について言えることだが、何らかの簡単なベンチマークを行なわなければ、結果を当に向上させることができたのかどうかを知ることはできない。Linux PC上では通常、数多くのプロセスが走っていて、それらが性能の測定に影響を与え

    ITmedia エンタープライズ:Linuxのパフォーマンスを改善する3つのTips (1/3)
  • blog.keitap.com: FFFFOUNDとnoatime

    スケーラブルWebサイトを読んでたらnoatimeの事が書いてあったので、画像を保存してるディスクをnoatimeでマウントし直したらロードアベレージとDiskのI/Oがえらい下がった。 (途中、データが取れてない部分がありますが、サーバがダウンしてたわけではなくて単に監視がうまくいってなかった) 再マウント時のコマンド: mount -o noatime,remount,rw /dev/sda2 画像配信のキャッシュサーバの方も同じくnoatimeでマウントしてみたけど、そっちはSquid使ってるのでキャッシュが単一のファイルの為効果はなし。 結論としては、大量のファイルを保有してる場合はnoatimeの効果は絶大だと。

  • Open Tech Press | Linuxのスワップ処理を最適化するためのヒント

    コンピュータのメモリ容量を超えるサイズのプログラムを実行する必要がある場合、最近のオペレーティングシステム(OS)のほとんどはスワップ処理と呼ばれる手法を用いる。これは、メモリ内データの大部分を一時的にハードディスクに格納しておき、必要なデータだけを物理メモリ空間に持ってくるというものだ。稿では、Linuxシステムにおけるスワップ処理の効率化とスワップ処理サブシステムのパフォーマンス最適化につながるテクニックを紹介する。 Linuxは、物理メモリの領域をページという単位に分割して処理する。スワップ処理とは、ハードディスク上にあらかじめ設定した空間(これをスワップ空間と呼ぶ)にページ単位でメモリ上のデータをコピーし、そのページのメモリ領域を解放する処理をいう。物理メモリとスワップ空間を合わせた容量が、仮想メモリとして利用可能になる。 スワップ処理が必要になる主な理由は2つある。1つは、物理

    Open Tech Press | Linuxのスワップ処理を最適化するためのヒント
    kgbu
    kgbu 2008/01/13
    swappinessなんていうパラメータ、あるんだ。
  • マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー

    ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった

    マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
  • 1