cfqスケジューラ Linuxカーネルは、ブロックI/Oの処理効率を向上させるさせるための仕組みとして、I/Oスケジューラと呼ばれる機能を提供しています。I/OスケジューラはI/O要求の順序を入れ替えることにより、スループットを向上させたり、特定のI/O要求を優先して実行させたりします。実際のブロックデバイスのセクタに対するアクセス（つまり読み書き）を、要求された順序ではなく、I/Oを最も効率よく行うためにその順序を並び替えるというアイデアは、初期のUNIXの実装から採用されていました。それは、セクタ番号順序に並び替えてI/Oを実行するという単純なものです。ディスク面上を移動するヘッドの動きがエレベータに似ているため、このアルゴリズムはエレベータアルゴリズムなどと呼ばれていました。 現在のLinuxカーネルでは、そのころのアルゴリズムより洗練されたスケジューリング方式を採用しており、目的に
現在のLinuxは、複数のファイルシステムが選択できる。だが、どれを選べばよいのだろうか？ ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する。（編集局） カーネル2.4から、Linuxは本格的にエンタープライズを意識したOSとしての機能を備えるようになった。その特徴の1つがファイルシステムの信頼性である。Linuxの場合、当初に実装されたext2からジャーナリングファイルシステムであるext3やReiserFS、そして商用ファイルシステムとして発展してきたJFSやXFSが取り込まれ、複数のファイルシステムが選択できるようになっている。 本連載は、これらのファイルシステムの違いを把握し、ファイルシステムを選択するための指針となるような情報を提供する。 ファイルシステムとは 私たちは通常、データの「読み込み」「書き込み」などの操
strace システムコールをトレース。カーネルと何を話しているか。 strace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 straceを使ったデバッグ - SourceForge.JP Magazine : オープンソースの話題満載 Linuxカーネルの作り出す世界 − ＠IT自分戦略研究所 - ふつうのLinuxプログラミング 青木峰郎 システムコールとライブラリ関数 − ＠IT自分戦略研究所 システムコール・ライブラリルーチン - UNIX の部屋 ltrace 共有ライブラリの呼び出しをトレース。*.soと何を話しているか。 ltrace -p PID でプロセスにアタッチ。実行中のプロセスをトレース。 ltrace で共有ライブラリの関数呼び出しをトレースする - bkブログ 404 - エラー: 404 - Linux JF ƒ‰ƒCƒuƒ‰ƒŠ‚ÌŠ
しばらくLinuxネタが続く・・。 近いうちに最近出たJava8ネタを書いてみようと思います。が、もう少しLinuxネタにお付き合いください。 前回はsshdを対象に親プロセスをkillした場合の動作を確認した。 killされたプロセスの子プロセスは孤児プロセスとなり、カーネルによって自動的にinitプロセスの子として扱われる事を説明した。（この動作を「リペアレンティング」と呼ぶ） 今回はこの続き。 Linuxで作業していてCtrl+Cしてプロセスを終了した場合、フォアグラウンドのプロセスやその子プロセスも一緒に終了する。 ということは、子プロセスは孤児として扱われず、リペアレンティングされていないことになる。 今回の記事ではこの振る舞いの違い（リペアレンティングされるか否か）に着目し、kill -SIGINTコマンドとCtrl+Cの違いについて考えていく。 そもそもkillコマンドやCt
スワップがなぜ起きるか、どのようにスワップの状態を確認するべきかの平易な解説。Quoraの質問に対する、Robert Love氏の回答。 質問に対するストレートな回答は、調べるのは不可能、だ。どうしてそうなのかを説明してから、君の知りたい情報を含んでいるであろう、5つの関連する質問に答えよう。 Linuxのような、モダンなOSにおいては、スワップはシステム全体における現象だ。ある1つのプロセスがスワップに関する責任を持っているわけではない。システムがスワップしているかどうかは、メモリプレッシャの機能による。物理メモリを大量に使おうとすれば、スワップしてしまう。何をスワップアウトするかは、一番少ないページを要求しているのが何かによる。何をスワップインするかは、一番ページを必要としているのが何かによる。プロセスがRAM上に存在しないページを要求した時、そのページはディスク上にあるので、スワップ
デーモンプロセスを作る場合には，教科書によく書かれている2度forkは不要ではないか? ということを以前の記事に書いた． [c][unix]UNIXネットワークプログラミングのお勉強 (2) デーモンの作り方 - 睡眠不足？！ 確かにBSDのdaemon(3) のコードでは，forkは1回しか呼んでいない． 「きっとプレセスがセッションリーダだと不都合があるのだろう．でもなぜ?」 というのがopen questionだった． それに対する答えを「詳解UNIXプログラミング」[1] に見つけた． SVR4においては，この時点でforkを再度呼び，親を終了することを勧める人がいる． 2番目の子がデーモンとして動作する．これは，デーモンはセッションリーダではなく， SVR4の規則 (9.6節) から，セッションリーダでなければ制御端末を取得できない，ということを保証する． あるいは，制御端末を取
なるほどUnixプロセス ― Rubyで学ぶUnixの基礎を読みました。UNIXプロセスの話、特に実用的なforkの利用方法についての話がコンパクトにまとまっていてわかりやすかったです。あまり詳細に踏みこんでいるという感じではないけど、とっかかりにこの本にあるような知識があるのは良いと思いました。(シェルスクリプトから"foreman start"したときにCtrl-Cで終了できない現象の解説 - はこべブログ ♨ではまる前に読んでおいたら、もっとはやく問題解決できたと思います。) 第18章 デーモンプロセスに関係して二回目のforkについていろいろ調べたので、せっかくなのでメモを残しておきます。*1 第18章 デーモンプロセス では、プロセスをデーモン化するために必要な手順が丁寧に説明されています。その中で、プロセスを制御端末から切り離す手順として以下のようなコードが紹介されていました。
不完全なデーモンプロセスに制御端末を割り当てる方法を教えてください UNIX のデーモンプロセスについて勉強しています。デーモンプロセスを作るには、 1. fork する (子プロセスを作って親は死ぬ) 2. setsid する (子プロセスを制御端末から切り離す) 3. もう一度 fork する (セッションリーダーではない孫プロセスを作って子は死ぬ) という手順を踏むのだと、後述のブログ記事等で知りました (chdir, umask, STDIN/STDOUT/STDERR などの取り扱いは、今回は注目しないので省略します) この 3. でやっている二度目の fork が必要な根拠として、セッションリーダーであるデーモンプロセス (1. で fork した子プロセス) に制御端末を割り当てられてしまうとまずいためだ、という理由が挙げられています (シグナルを送られてプロセスを操られてし
C言語でネットワークプログラムを実装する際のメモ。動作環境はLinux系OSを対象としている。 TCPのkeep-aliveオプション ソケットを開く際に、TCPのkeep-aliveオプションを設定するとアイドル状態が続いた際に、プローブパケットを送出し、通信相手との接続を確認し維持しようとする。逆にプローブパケットにACKが帰ってこないと通信相手との切断を検出できることとなる。 デフォルトではアイドル状態が7200秒=2時間経た後、プローブパケットを75秒間隔で9回送信する。プローブパケットに対するACKの応答がないと、通信相手がいなくなったと判断し、アイドル状態の通信を終了する。 つまり、アイドル状態に入ってから、7200秒＋75x9秒=7875秒 = 131.25秒 = 2時間11分経過すると通信を終了する。なお、SO_KEEPALIVE ソケットオプションが有効になっていないと
Post navigation ← Previous Home > Web関連 > 開発 > Linux > Linuxカーネルチューニングのメモ Linuxカーネルチューニングのメモ サーバー向けにLinuxカーネルのチューニングを行った際のメモです。 設定内容 今回行った /etc/sysctl.conf の設定内容は書きの通りです。 各パラメータの説明はコメントとして残しておきます。 # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824 # システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144 # システム全体のプロセス数の上限 kernel.threads-max = 1060863 # システム全体のファイルディスクリプタの上限 fs.file-max = 5242880
Quite often in the course of troubleshooting and tuning things I find myself thinking about the following Linux kernel settings: net.core.netdev_max_backlog net.ipv4.tcp_max_syn_backlog net.core.somaxconn Other than fs.file-max, net.ipv4.ip_local_port_range, net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, and net.ipv4.tcp_wmem, they seems to be the important knobs to mess with when you ar
$ dmesg ....... possible SYN flooding on port xxx. Sending cookies. possible SYN flooding on port xxx. Sending cookies. possible SYN flooding on port yyy. Sending cookies. possible SYN flooding on port yyy. Sending cookies. possible SYN flooding on port xxx. Sending cookies. possible SYN flooding on port xxx. Sending cookies. possible SYN flooding on port xxx. Sending cookies. Cause This could be
Last modified: 2009-04-27 (月) 16:06:34 (5592d) [ トップ ] [ 差分 | 一覧 | 最終更新 | ヘルプ ] 32bit Linuxで3GBの壁を超える！ 3GB以上の物理メモリをLinuxに認識させる場合には物理アドレス拡張(Physical Address Extension; PAE)に対応したカーネルが必要になります。もちろんマザーボードも対応している必要があります。物理メモリの上限に関しては詳しい解説が探せばいくらでもあるので適当に探して下さい 。 マザーボードによっては4GB積んでも3.2GBぐらいしか認識しないもの(AOpen XC cube EZ965; 使用できるのは3.2GBって書いてありましたが、memオプションのチューニングによって3.7GBあたりまで認識させることができました)、6GB(2+2+1+1)積んで6GB
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは 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 程度と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
