何か決めなきゃ駄目ですか。 Linuxのbacklogについて
少しだけ突っ込んだ話。 （曖昧さは人間の脳内補完に委ねるとして･･･。） LinuxにはTCPの3Wayハンドシェイク（即ち、SYN,SYN/SCK,ACK）状態保持に関連して、 次のようなパラメータを持っている。 net.ipv4.tcp_max_syn_backlog=1024 何それ？って人は # sysctl -a | grep tcp 等のコマンドで探します。 # sysctl -a | grep backlog？それじゃノイズが無さすぎて面白くｎ(ry これは、「LinuxがSYNを受信し、SYN/ACKで応答した状態をいくつ保持するか」というもの。 閾値を超えると、Linuxは新規に接続しようとするホストのリクエスト（SYN）を無視する。 最近のLinuxを、最近のハードウェアにとりあえずインストールすると、 初期値は上記のような1024とか言う数値になっていると思う。 利用
見落としがちなLinuxのWEBチューニング | Act as Professional
WEBコンテンツ配信にLinuxを使うのは一般的になりましたが、CentOSやUbuntuをはじめ、大抵のディストリビューションが低スペックなマシンでも動くような初期設定になっています。 トラフィックの上限でもない CPUリソースの枯渇でもない HDDのIOが遅い問題でもない コンテンツが重くなる(接続できない) というケースで、見落としがちなLinuxのネットワーク周りのチューニングについてです。 iptables関連 iptablesを使用している場合、下記のパラメータを注意して下さい。 /proc/sys/net/ipv4/ip_conntrack_max ip_conntrackに記録できる最大値です。65536あたりが初期設定になっているかと思います。これだとパケットの取りこぼしがすぐに起きてしまいます。1コネクションあたり約350バイト消費するので、実装されているメモリに応じて
Linux の TCP/IP チューニング・パラメータ
TCP のチューニング・パラメータ 接続確立関係のチューニング・パラメータ TCP のチューニング・パラメータ TCP のチューニング・パラメータは、以下のコマンドで取得できます。 なお、以下は Linux のものです。 >cat /proc/sys/net/ipv4/tcp_retrans_collapse 1 >cat /proc/sys/net/ipv4/tcp_keepalive_probes 9 >cat /proc/sys/net/ipv4/tcp_keepalive_time 10800 >cat /proc/sys/net/ipv4/tcp_syn_retries 10 >cat /proc/sys/net/ipv4/tcp_sack 1 >cat /proc/sys/net/ipv4/tcp_timestamps 1 >cat /proc/sys/net/ipv4/tcp
スワップサイズをゼロにしてはいけない
先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、本書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、この本をほめてくださっていることに大変感謝しています。まだ本自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして
oprofileで性能分析→ボトルネック特定
性能分析に有用な性能監視ツールOProfileを見つけたのでメモ。CPUのイベント（キャッシュミスなど）を計測することができるらしい。 OProfileのサイト http://oprofile.sourceforge.net/ Linux Kernel Profiling HOWTO http://www9.ocn.ne.jp/~puppet/docs/Linux-Kernel-Profiling-HOWTO/x86.html ↑具体的な使い方が載っている コードを読むな、理解しろ（ユメのチカラ） http://blog.miraclelinux.com/yume/2006/10/post_e3d6.html ↑ソースから、キャッシュミスの多発している行を特定するのにOProfileを活用。 http://blog.miraclelinux.com/yume/2007/08/post_89
OProfileを使ってCPUプロファイリングをとる - PS3 Linux Information Site / Cell/B.E.のパワーを体験しよう
OProfileとは Linuxシステムで使えるプロファイラです。 カーネル内で発生したイベントごとにサンプリングを行うので、カーネル内も含めたシステム全体のプロファイルを取れるのと、ハードウェアパフォーマンスモニタの値を取得できるのが特徴です。 ハードウェアパフォーマンスモニタが実装されていないシステム上でも、タイマ割り込みごとのサンプリングが利用できます。 このタイマ割り込みを使ったプロファイラはアーキテクチャに依存しないため、PS3 Linuxでも使用することが可能です。 なお、以下の解説は、バージョン0.9.1をもとにしています。 OProfileのインストール OProfileを使うには、OProfileツールのインストールと、Linuxカーネルに含まれるOProfileモジュールのコンパイルが必要です。 OProfileツールは Fedora、もしくはFedora Core
Disk Allocation Viewer
DAVLとは DAVLの機能概要 スクリーンショット リンク このプログラムの一部は、「独立行政法人 情報処理推進機構 オープンソースソフトウェア活用基盤整備事業」に 係る委託業務の一環として開発しました。 DAVLとは DAVL(Disk Allocation Viewer for Linux) はLinuxファイルシステムext2/ext3の フラグメンテーション状況を可視化するツールプログラムです。 ファイルシステムのマウント状況によらずフラグメンテーション状況を取得でき、 それをテキスト形式で出力したり、GUI 表示したりすることができます。 DAVLプログラム DAVLは下記の２つのプログラムよって構成されています。 ファイルシステム情報取得プログラム ディスク割り当て可視化プログラム また、DAVLには次のカーネルモジュールも含まれています。 ファイルブロック情報取得モジュール
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
xfs_fsrを使ってXFSファイルシステムをベストの状態で使用する | OSDN Magazine
XFSファイルシステムは大規模なファイルの保存/アクセスについての性能が高いことで知られている。XFSの設計はエクステントベースで、ファイルの内容は一つ以上のエクステントと呼ばれる連続的な領域内に保存されている。XFSファイルシステム内のファイルは、ユーザの使い方によってはフラグメント化することがあるが、xfs_fsrユーティリティを使ってそのようなファイルをデフラグすることでファイルアクセスについてのシステムの性能を向上させることができる。 ファイルをXFSファイルシステム上にコピーすると、通常は一つのエクステント内にファイルの全内容が保存される。しかしその後ファイルを延長したり新たなデータで内容を書き換えたりしようとする際には、ファイルの直後に続く領域が利用できないこともある。その場合、ファイルはディスク上の別々の場所にある2つのエクステントに分かれて保存されることになる。当然ながらフ
第2部第3回 ハード・ディスクをチューニング（その1）
IAサーバーに限らず，一般的に，最もボトルネックになりやすいコンポーネントとしてディスク・サブシステム（ハード・ディスク・ドライブを含むコンポーネント）がある。ハード・ディスク・ドライブはサーバーの中で数少ない機械仕掛けで動作する，最も低速なサブシステムである。そのため，適切なチューニングを行っていないと，データの処理スピードが遅くなってしまう。逆に，適切なチューニングを施してディスク・サブシステムを高速化することにより，劇的なパフォーマンス改善を図れることが多い。ハードウエア・チューニングにおいては最も注意を払うに値するコンポーネントだ。 ここで，このコンポーネントだけディスク“サブシステム”と記述している理由について説明しておく。サーバーでは，ATAハード・ディスク・ドライブや SCSIハード・ディスク・ドライブを単体で使用するのではなく，後述するRAIDを用いて複数の物理ディスクを1
LinuxのファイルI/Oチューニングに使える「Iotop」 - GIGAZINE
ファイルI/Oがパフォーマンスのボトルネックになっていることはなんとなくわかるが、具体的にはどうなっているのかを知りたい場合、通常はvmstatやiostatなどを使うわけですが、この「Iotop」を使うと、いわゆるtopコマンドのような感じで表示してくれるので、ケースによってはかなり状況を把握しやすくなり、非常に役立ちます。 詳細は以下。 Iotop's homepage http://guichaz.free.fr/iotop/ 中身はPythonで書かれており、Python2.5以上とLinuxのカーネル2.6.20以上で動作します。 画面はこんな感じ あと、ディスクI/O関連は以下のページも参考になります。 Linux I/O のお話 write 編 - naoyaのはてなダイアリー Linuxチューニング 第2部第3回 ハード・ディスクをチューニング（その1）：ITpro
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
performancewiki.com - performancewiki リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
ほえほえ LinuxファイルI/Oチューニング
Linuxは私の使っている範囲ではファイルI/Oがパフォーマンスボトルネックになっていることが多い。で、チューニングの情報を集めてみるのだが、なかなか役立つ情報を入手できない。 決まって全般的なチューニングの進め方について述べ、次にボトルネックの調べ方について述べる。 最後にチューニングパラメータ設定手順のヒントだけを非常に簡単に挙げておわってしまう。いや、どこがボトルネックなのか最初に一発で分かればいいよ？ でも全般的なチューニングの進め方でそうしたドキュメントが述べている通り、色々な可能性を繰り返しチューニングしながらつぶしていかなきゃいけないんだよね。 そのためには具体的なチューニングパラメータの設定手順がなきゃできないんだよね。それを教えろよ！それを！ ということで、今回はLinuxファイルI/Oチューニングについて調べた。大きなファイルの書き込み(ex. cpコマンド)を行うと、
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 を高速なものに交換する以外ありません。 というわけで
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
