IBM DeveloperIBM 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.
プロセスの優先度＠CetnOS 5.5
Linuxのプロセス優先度には、大きく分けて2つあります。 静的優先度 (リアルタイムプロセス)と動的優先度です。 Linuxカーネルの内部では、優先度は1～139で表現され、1～99が静的優先度、100～139が動的優先度になり、値が低い方が優先度が高くなり、動的優先度はカーネルにより動的に変更されます。 静的優先度は、スケジューラにFIFOとRR(ラウンドロビン)の2種類選択することができ、FIFOは一度CPUをつかむとCPUを離すまでずっと使い続けることができ、RRは同じ優先度のプロセスがあると、ラウンドロビンでCPUが割り当てられます。しかし、どちらのスケジューラを選択しても、優先度の低いプロセスにはCPUが割り当てられないので、設定するには注意が必要で、最悪PCがフリーズしたような状態になります。 優先度を表示するコマンドにより、この優先度の表現が異なるため注意が必要です。 まず
プロセスの優先度 - Linuxカーネルメモ
通常のプロセス(非リアルタイムプロセス)には静的優先度と動的優先度の2種類の優先度がある。 静的/動的優先度どちらとも値が小さい方が優先度が高い。 1. 静的優先度静的優先度は0〜139の値を取る。このうち、0〜99はリアルタイムプロセスに使用される。通常のプロセスは100〜139になる。 静的優先度はプロセスのnice値により固定的に決まる。niceは-20〜19の値を取るが、これをそのまま100〜139にずらした値が静的優先度となる。 nice値 -20 ... 0 ... 19 静的優先度 100 ... 120 ... 139 静的優先度はtask_structのstatic_prioに格納される。 2. 動的優先度動的優先度は静的優先度をベースにCPU使用量に基づいて算出される。スケジューラによるプロセスの選択時には動的優先度が使用される。取り得る値の範囲は静的優先度と同じ100
新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
Linuxカーネル3.11リリース、安全な一時ファイルを作成するフラグや細かな新機能追加が行われる | OSDN Magazine
Linus Torvalds氏は9月2日、Linuxカーネル3.11を発表した。安全な一時ファイルを作成できる「O_TEMPFILE」フラグの導入やNFS 4.2のサポート、swapページを圧縮して格納する「Zswap」といった新機能の追加などが行われている。 6月末に公開された3.10に続くリリースとなり、約2か月での最新版リリースとなる。このバージョンは、今年で発表から20年を迎えた「Windows for Workgroup 3.11」にちなんで「Linux for Workgroups」というコード名が付けられていた。ロゴもペンギンがWindowsの旧マークの旗を持ったデザインとなっている。なお、正式リリースを発表したTorvalds氏は直前の7回目リリース候補（RC7）公開を告知しなかったことを認めている。 新機能としては、安全に一時ファイルを作成するための「O_TEMPFILE
/proc/meminfoを考える - めもめも
通りすがりの貴方・・・・ /proc/meminfoのあっちの値とこっちの値を足したら、なんでそっちの値と同じにならないの・・・・ と悩んだことありますよね？ /proc/meminfoは、カーネルが内部的に管理している枠組みでのメモリ情報をそのまま出しているので、残念ながらユーザ視点で知りたいメモリ情報とは一致しません。 とはいえ、変な解釈をして無意味に悩まないために、それぞれの値の意味合いと項目間の関係を知っておくのは有意義です。私の理解の範囲で、それらの関係をまとめていきます。 ＃私の理解も完璧ではないので、間違いあればやさしくご指摘お願いします。 参考資料 http://mkosaki.blog46.fc2.com/blog-entry-1007.html 2011/09/07 追記： tmpfsがSwapCachedに含まれるのは幻想でした。tmpfs=Shmemに修正しました。
Linuxのサーバをリモートから強制的にOSリブートする - 元RX-7乗りの適当な日々
先日、諸々の都合で遠隔にあるテスト環境のサーバ(Linux)のカーネルパラメータを弄っていたのですが、ちょっと設定(メモリまわり)がイキすぎてしまいｗ、コマンド実行というかforkできなくなってしまった(Cannot allocate memory...)。 んで、shutdownコマンドも実行できなくなったので、直そうと思ったのですが、色々弄った＆時間がなかったこともあり、一旦OSを再起動しちゃいたいな、と(汗 が、遠隔にあるサーバなので、物理的な電源スイッチON/OFFができない(厳密には出来る環境ではあったのですが、このサーバはそこに入ってなかったｗ)。ので、SysRqキーを送ることにした。 やり方 少し無理矢理感はありますが、 # echo b > /proc/sysrq-triggerを実行すると、強制的にリブートがかかります。 ただし、ファイルシステムのsyncとかumount
マルチコア時代のロードアベレージの見方 - 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分ごとのシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
