brand new note

ジャズ屋が技術の話をするところ

ポストモーテムって何

久しぶりに書き物がしたくなりました。 ふらふらと役に立ちそうな記事を読み漁っていたら気になる単語を見つけました。ポストモーテム、なんだか失敗談を書き記すような文化のことを言うらしい。2分で読んでただ感心したということをメモにしているだけですので、正確な情報ではないことをあらかじめご了承ください。

ポストモーテムの文化 - エムティーアイ エンジニアブログ

人間の失敗を記したドキュメントは陳腐化しない - non117's diary

外部向けのドキュメントではなく、自分達の組織をより良くするために書く内部向けの文章、という特徴があるようです。失敗談を書く理由は同じ過ちを次の世代に残さない為。うまくいかなかったことを文書として書きためれば、時とともに適切な判断が可能になっていきます。

ドキュメントにも色々ありますよね。エンジニアが外向けに文書を出すときに書くものは成功体験や実験の成果であったり、あるいは説明責任を果たす為に書かれるものであったり(自分が書いた事はありませんが…)。内向きであれば組織内で使われる技術の使い方だったり。自分もブログの他に、研究室内のwikiをたまに管理することもありますし、もちろん必要に応じてメールもスライドも書きます。記事を読んでいて、現環境の内外で意識的に文体や伝えたいことをうまく書き分けられているのだろうか、などとぼんやり考えてしまいました。

ソースは最近有名なSRE本だそうで、いえ、ぼくは読んでないんですけど。ただ漫然と毎日を繰り返すよりも意識的に失敗談を記録したほうが血肉になる感覚は日々感じるようになってきています。だからなんとなくこれらの記事が目に留まったのかもしれませんね。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

 

ところで

随分とブログの更新に間が空いてしまいましたが、自分が文章をなんとなく書き留めることは変わらず好きで。近頃は抽象的なことしか考えられなくなってきたもので、しばらく他人の目に見せられるような文章は書けないと思い自粛していたのですが、そろそろそんなものでも日々思ったことを書ければいいのかな…などと思い始めております。(ほんとは去年の夏から日の目を見ていない書き物が75万字くらいあるんですよ。。。)

この記事を推敲していたら、意味が破綻してる文章しか書けなくなってきていることに気づきました。人に見せるものは脳からダイレクトに気持ちを取り出すような書き殴りかたをしないようにしないといけませんね…

あけましておめでとうございます

今年もよろしくお願いいたします。少し遅れましたがこの場で2018年の振り返りと2019年の目標を書いておきます。

2018年の反省

去年はM1、同期はほぼ皆就職、残った院生と共同研究者の方々は強者揃い…ということもあり、大学生気分をなんとか抜きたいだとか、自分の意志で何をどこまでやれるのかとか、そういう気持ちが大きかったように思います。特に下半期にかけてはモチベーションが完全に逆転し、恥ずかしいはなし勉強のほうは芳しくなかったのですが、結果として、エンジニアとしてでなくひとりの人間として何に心地良さを感じるのか、今、ひいてはこれから先、自分の心が折れたらどう立ち直ればいいのかを知る年となりました。

自分の実力の伸び悩みに対する対処について、うまく立ち回れなかったのが2018年かなと思います。現在も解決できていないもやもやしたものが色々ありますが、それを踏まえて2019年の目標と行動指針を立てたいと思います。

2019年の目標

  • うまく他人を頼るとはどういうことか学ぶ
  • 自分のペースで勉強するが、常に興味を失わない
  • 知識の吸収率に対する合格ライン(ハードル)を下げる
  • 悩みに対するより良い向き合い方を探す
  • 居心地のいい空間と人を探す
  • 留年しない()

人間的にも技術的にも自分の未熟さに苦しみ、それでもいいから一度は自分の意志であれこれやってみたいというのが去年の感覚でした。自分でも抑えが効かないほど色々なことに悩み、ご迷惑もかけてしまいました。故に、これまで他人を頼って成長してきた部分は大事にし、また自分のペースも見失わず、うまくバランスを取っていけるようになることが今年の大きな目標です。

 

個人的な悩みは割愛しますが、モチベの部分でうまく立ち回る方法のひとつとして、当ブログは継続して書いていきたいと思っています。ただ、あまり皆様が読んで勉強になるような良い記事は書けないかもしれません。あと10年くらい待ってください()

ブログも含め研究以外での勉強は、自分でインプットアウトプットの質を若干低くすることを許容しようと思っています。院生だしもっと頭よくなりたいみたいな自分自身の縛りに疲れました。技術的に優れた記事を書く方はたくさんいらっしゃるので頭が上がりませんが、それを見て何も手が出せなくなるようなことを避けたいと思っています。そんなわけで技術的な目標は具体的には立てず、気になるものを広く浅く調べようと思っています。

 

あとまあ下の目標は…修論と就活の話ですけども…。今は技術的に優れているかどうかよりも、長く穏やかな心で続けられるお仕事を探したいなという気持ちのほうが強いです。研究室の皆様の引き立てのお陰で、学部時代の漠然とした不安はほとんど消えました、感謝しかありません。まだまだ未熟ですし更なる飛躍をという気持ちもありますが、これから長く働く空間は慎重に選びたいと思っています。何卒よろしくお願いします。

進捗率を表示するpvコマンド

aptとかyumしたときに表示される進捗率をあらわすプログレスバー。pvコマンドを用いると簡単にこれを実装することができます。時間がかかる処理を自作した場合に対して有効です。使ったことがない方はまずインストールしてみましょう。

sudo apt install pv

使い方

時間がかかる処理ということで、試しに大きなファイルの圧縮をやってみましょう。まず500MBのダミーファイルを用意します。

dd bs=500000000 count=1 if=/dev/zero of=bigfile1.dat
dd bs=500000000 count=1 if=/dev/zero of=bigfile2.dat

ダミーファイルの作り方の説明はこちら

/dev/zeroってなんだ - brand new note


次に作成した二つのファイルをアーカイブし、圧縮します。tarの引数に-を指定することによって、コマンドの出力を標準出力に出すことができます。これにより、パイプで進捗率をpvコマンドに渡すことが可能になります。最後にgzipコマンドに渡して圧縮します。

tar cf - bigfile1.dat bigfile2.dat | pv | gzip > archive.tar.gz

 

ikeda@DESKTOP-4B08IPQ:/tmp/myapp/datadir$ tar cf - bigfile1.dat bigfile2.dat | pv | gzip > archive2.tar.gz
 953MiB 0:00:06 [ 137MiB/s] [            <=>                                                                           ]

プログレスバーで圧縮中の様子を観察することができます。左から順にトータルのデータ量、経過時間、処理速度が出力されているのがわかります。

参考

UNIXシェルスクリプト マスターピース132

UNIXシェルスクリプト マスターピース132

 

4Kモニタを買いました

はい。タイトル通りの報告となります。

 

うちにはモニタらしいモニタがなく、HD, 23.5inch というごく普通のテレビにPCを繋いで作業するだけだったのですが、ようやく購入に踏み切りました。こちらです。

輝度のダイナミックレンジが広がるHDR機能付き4Kモニタで4万円強は現時点で最安クラス。パネルはTNよりIPSやADSが良いとのことで…。ためになります。 HDR機能およびディスプレイのスペックの見方については、ざっくりした説明がこちらに記載されています。

www.eizo.co.jp

つなぐ

f:id:frazz:20181024134021j:plainf:id:frazz:20181024134040j:plain

うちのデスクトップPCは4K出力ができないので、対応できるのはジャンクで買ってきたX250のみ。もはやジャンクPCの仕事量を超えています…。miniDP to 4K-HDMIを挟んで出力します。試しにyoutubeで4K動画を流してみたところ、かくつきましたがなんとか再生可能でした。

 

ケーブル規格の調べもの

入手できたうちのminiDP to 4K HDMIはこちら。

www.mco.co.jp

こいつが4K30p と FHD60p の2パターンにのみ対応しており、4K60pは出せないことが判明しました。4K30p=現在最も普及しているHDMI1.4(max10.8Gbps) , 4K60p=ちょっとレアなHDMI2.0(MAX18Gbps) なのですが、ここが60pに対応していないとHDMI2. 0を買っても意味がないんですね。しかもサブ機のX230に至ってはFHDすら出せないからそもそも出力不可能…。くそう…。

まあよく考えたらこんな細いのが18Gbpsも出せるわけないんですが、調査不足でした…。30pでもきれいなので許しましょう。ちなみに上記のHDMI規格を調べていないと、世の中には30pしか出せないのに堂々と4KHDMIって書いて売られているケーブルが多数存在しますので、とっても気になるという方であれば購入の際に注意してみるとよいと思います。ゲーミングPCを買うような方々が主に気にするのかな?

https://ja.wikipedia.org/wiki/HDMI#HDMI_2.0

 

まあそれはともかく

写真だと伝わりにくいんですが、家でこの画質が見られると相当こう…テンションに…影響しますね。鮮やかなんですよ白がクリアで黒がシャープで!!()

サイズが27inchで、90cmのメタルラックに悠々とのっかるくらい。他の皆様のレビューの通り、27inch以上になるとちょっと作業がしにくくなってしまうのでこれくらいが満足度が高いのかなあと思います。解像度150%くらいにして文字サイズ的にはちょうどいいくらいで、まだ高精細になる余力を残していると考えると非常に作業中の充実感は得られるんじゃないかなと思います。

f:id:frazz:20181024141804p:plain

本気出すとこんな感じで、相当数ウィンドウを開いても重ならなくて済むのがなんとなくご想像いただけるかと思います。

皆様も興味があればぜひ!

知識を構造化するためのテクニック

発端

最近どうやって知識を効率的に入れるか、頭と体をどう使えばいいのかを考えています。読書術とかメモ術とか脳のちょっとした仕組みとか、心理学の端っことか…そんなことをひたすら調べています。

そこでqiitaの一記事が目に留まりまして、研究なり、ものづくりなりをしていくときに参考になりそうだったのでメモしておきます。最近出たエンジニアの知的生産術という書籍が有効なようで、まとめのまとめみたいになって恐縮なんですが…。自分なりの解釈で再構成しています。参考記事や原著が気になる方は一読しておくとよいと思います。

qiita.com

 

理解できないことを学ぼうとしない

分からないことに時間を割くのはやめる。これが難しいのですが慣れるしかないのかなと思います。

というと雑すぎるので追記。この学ぼうとしない、というブレーキ(肯定的諦め)はどこでかければいいのでしょうか。考えてみましょう。

ものには基礎があるので、今学んでいるものが基礎なのか、それとも基礎ではないのかをまず初めに理解する必要があります。初心者からすると何が基礎なのかわからないという壁にも当たるのですが、わからないならわかるものからやるか、先人が基礎って言ってるんだったら大人しくやってみるの2択になります。

これを学んだら何ができるようになるのか、何が楽しいのか、どの程度価値があるのか、誰が喜ぶのか、次の勉強にどう繋がるのか、などを自問自答すると、「理解できないがやる価値はあると思う」という選択はあえて取れるようになるのかなと思います。この場合、ちょっと頑張ってやるといいと思います。

その後に、「じゃあこの一文の理屈は理解できるか」「この単語の意味の説明は理解できるか」「今理解できないのはどれのどこの箇所のせいか」を掘り下げていくといいのかなと思います。

最終的には時間で区切ります。ここまでやったが、ここがわからなかったという記録を残すのがよいです。ノートか、あるいは他者に報告するかですね。ここまできて初めて「理解できないことを切り捨てる」ことになるのかなと思います。これを意識して最善を尽くして回数をこなします。そうすると勉強の質が高まっていきます。これを先に書いた「慣れ」と呼びます。

これは技術以外の疑問にも適用できます。

時と場合によってはよろしくないですが、作業の区切りはやる気で決めることもままあります。

事実の暗記より先に全体像を学ぶ

インターネットの記事よりもいろんな書籍を読み漁ることでこれは練習できるかもしれません。まったく技術的なジャンルでなくても、です。感覚を身につけるものと割り切れば応用できます。

3年前の自分はとにかく活字がダメだったので多読していて自分の立場からこんなことを書いていたんだろうなという印象ですが、一応この記事の原型として残しておきます。全体像を掴むのもこつがいるので、そのための多読は間違いではないと思いますが、ここでは暗記のよくない点と全体像を掴むことの重要性を再考して行きたいと思います。

ありがちな例として暗記はテストでいい点数を取るための対症療法、という使い方をしてしまうのですが、それは損してるなあと思います。真の学びは体の底に実感としてたまっていくものです(偉そう)。どのくらい腹の底から自分がやってることに大義を感じたいかにもよりますが、できるだけ暗記よりも思考を通したほうがいろんなことが腹落ちしますし、ただの暗記ではこの体感も今後の積み上げも薄くなってしまう気がします。暗記に頼ると脳の限界が早めに来てしまい成長が一定のラインで上げ止まりになります。その結果取り越し苦労になったり身につかない徒労になることも多いです。それをたくさんやって「おかしいことを実感」するのも無駄ではないと思うのですが。

というわけで、結局腹の底からものを理解して記憶しようとしたら、最初に全体像を知ってものを抽象的に理解することが不可欠だな、というところに数こなしてると行き着きます。勉強中「そういうもんなのか」という言葉を発したことはあるでしょうか。漠然とした理解とそれに伴う不明点が生まれるのは、人によってはものすごくイライラモヤモヤしがちなのですが、これは勉強の一つの過程であるため必要経費として割り切ります。それをすっ飛ばしてでも細かいことがわかるのがいいというのは筋違いで、「こんなこともわかってる自分はすごい」という自己満足に終わってしまっている可能性があります。そうならないためにも雑学やうんちくより物事の俯瞰を大事にしましょう。

基礎から積み上げる

上と重なりますが、細かいことよりも難しくてかっこいいことよりもまず基礎です。基礎は今後学習が縦に積み重なっていくための大事な情報です。なので、最初の一歩ということで細かいことに見えてもやっていくのがいいと思います。腹落ちしなければ暗記も可です。やらないとそこから先にも行けないです。

挫折しないコツとしては、できるかぎり自分で思考してその情報を意味のあるものとして体に落とし込むことです。本を書いた人もサイトを立ち上げた人も人間なので、どんなに難しそうでもその書き手が何かしらの理屈に伴った思考をしてその文章を生み出したわけです。なので、「これがないと何がダメなのか」「反対の順番で学んだら何か不都合が起こるのか」「なんでこれを作った人はこんなものを作ろうと思ったのか」などの疑問を投げかけてみてください。そうすると「こうなんじゃないか」「今は分からなくてもいいんじゃないか」「そこはもっと良くしたほうがいいんじゃないか」など、自分なりの結論が出てきます。それが間違っていたとしてもちゃんと思考し続ければ後で自分で矛盾に気づけますので、とりあえずは自分なりの理解を持ってして基礎のゾーンを突破するイメージを持つのがいいかと思います。まさに暗記の対極ですよね。

複雑な知識は細分化し、一つの疑問と答えをセットにして短く記憶する

疑問と答えをセットにして短く記憶する、というのは「とにかく考えるというのを数こなしていけ」という意味です。短ければ無思考でも暗記できるからいいね、という意味に取ってはいけません。無思考の暗記こそ脳の容量を無駄に消費するのであまりおすすめしません。「なんでこの年に事件が起きたのか?→その前の10年で景気が後退していたから」「なんでAくんのイヤホンは赤いの?→ビビッドカラーの方がテンションが上がるでしょ」「なんでパクチーが嫌いなの?→匂いが嫌で」のような、中間の思考をよく見ましょう。そうすることで腹落ちし、同じことを1ヶ月後に聞かれても同じように回答できます。結果的に脳のリソースを別のもののために空けることになるのです。

穴埋め問題は効果がある

これは効果を実感してないのでなんともいえません。記事を書いた当初に一度やりましたが当時は良さがわかりませんでした。よく考えたら埋められるというところを穴にして思考実験したり、作問の過程で重要な点を理解してどこを穴にするのか考えてみることそのものに効果があるのではないでしょうか。解くだけの立場でいるとおそらく旨味は半減すると思います。

画像を使う

メモでもスライドでも図や絵を多用したり矢印で因果関係を意識的に書く方が頭に入りやすいです。紙、PCは関係ありません。思考の整理には重要です。自分みたいなめんどくさがりでも簡単にPCでお絵描きできるようになると嬉しいのですが、ちょっとその苦労を買うところにはまだ行けていません。本当は好き好んでいつでもそんなことができたらかなりアドバンテージなんですけどね。まだ文章書くほうが好きですね。

記憶術を使う(マインドマップ等)

これはいっぱい出てくるので各自調べてみてください。自分は使いこなせていないのでまだ語る権限がありません。

順序のない情報の集合は記憶しにくいのでインプットの対象から外す

割とこれが大事で、例えばやみくもにコマンドオプションを覚えても使わなければ意味がありません。意味がないというのは実際にマシンをどうこうするのがエンジニアの本分であって、コマンド集を作ることがエンジニアの本来の仕事ではないということです。実際それが向いている方はぜひとも良い世の中のためにお願いしたいのですが…。

長く記憶しにくいだけでなく、闇雲な記憶は実践で使いにくいです。

たとえば目玉焼きの作り方の手順のひとつひとつが書かれたボードが散らばっていて、Aさんはそれをもとに目玉焼きの作り方をマスターしたいとします。ここで何もわからないAさんは手当り次第に書いてあることを実行するとします。まず「卵を割る」を最初に拾ったとしましょう。Aさんは卵を割りました。卵はボードと一緒に床に散乱してしまいました。次に「水を入れる」を拾いました。Aさんは水も床にぶちまけました。

順番がわからないまま記憶をするということはこういうミスを生む危険性を持っているのです。Aさんほどやらかす人はそうそういませんが、ここをわかっていなかったり自分の能力以上のことを闇雲に記憶しておくと実践で大変なことになります。

順番を覚えるのが苦手な人も、ぜひ実践で自分の身を守るためにインプットの方法は実利につながる形で正しくやっていきましょう。

似たようなものは一度に覚えない

記憶違いが起きやすいので、「○○ ×× difference」とか「○○ vs ××」のようなググり方をすることは多いです。しかし、そこから「あー○○はこうだったのね」と言ってその場がしのげたところで、1ヶ月後にもう一度検索せずに同じ知識を思い出せるでしょうか。たぶん、やっぱりわかんなくなってもう一回検索すると思います。そして、その場合って目的が調べ物になってますよね。これは時間の無駄です。本来の目的でいえば、実践に使う片方の情報が正しく記憶できているかさえ確認できていればいいのです。

なので、こういった場合には片方だけしっかり記憶するのが良いと思われます。資格の勉強とかしてるとそうもいかない状況になりそうですが、実践で知識を使う場合にはその実践の体感で記憶できたりするものなので、実は類似の知識と比較して思い出したりしません。ミスを減らすためにも厄介じゃない確実な記憶をしましょう。

言い回しを最適化する、知識を自分の体験と絡める

レポートを書いていても「自分の言葉に直してください」と言われるのでこれは学生でもわかりやすいところかと思います。こと記憶においては、「気づき」に重点を置くのが大切で、「こう思っていた。こういう体験をした。そこでこういうことに気づいた。つまりこれが大事なのだ。」というようなエピソードを探すように生活していると、勝手に知識は体に入っていくと思います。机上の勉強よりも体験や面白い話を混じえた方が記憶には残ります。ただし、情報の正当性とか論理の正当性とか仕事上で使えるコミュニケーションか否かとかは論点に含みませんのでご注意ください。あまり人前で使うと胡散臭い人になります。

冗長性ある記憶方法は最小情報原則に矛盾しない

ひとつのものごとを記憶するときは、圧縮しても解凍しても意味のあり方が途中で変化しないようにするっていう意味合いかと思います。「要は」とか独り言の口癖にしておくといいです。こうして情報の加工をひとりでにできるようにする中で記憶の定着を図ります。楽しみながらやるのがいいと思います。

日付を記録する

学んだ時期を見直す仕組みを持つことで思い出すスピードを短縮できます。自分は日記のタイトルを日付にしていて、なんでもその中に気がついたことを書いてるのですが、「前にも同じこと悩んでなかったっけ…?確か○月だよね」というところまでは何も見ずに思い出せます。昔の自分からすれば考えられないことです。思い出や体験と絡めて記憶するのも相まって日付は重要な情報になります。

優先順位をつける

ぜんぶだいじと思ってるとこれがうまく行かないんですよね。自分が今読んでいる文章の中から何が最も重要なのかを取り出す訓練をしていくのが大切です。細かい具体的な情報ほどただのページ稼ぎになっている場合があるので、覚える優先順位を見破るヒントにしてください。あるいは、この文章のように「説明だからわかりやすくしようとして長くなる」場合もあります。インプットするときは「こんなんどうでもいいだろ」とか、「それってつまり何が言いたいの?」とか言いながら文章を読んでみると優先順位は見えてくるかと思います。もちろん主観でどうでもいいとか思ったらミスリードしますので、もし本当に大事な内容がガチでつまんなくてもそこは履き違えないようにしましょう。

 

また、この本以外においても「図や画像で記憶する」「試験問題を解く」「問題を手を動かして作ってみる」などの学習方法が、より主体的に取り組めるため効果的という話をちらほら耳にしています。エンジニア以外の勉強にも使えるテクニックが多いようですが、これをちょっと頭に入れておくだけで色々捗るのではないかと思います。

 

※2021/06/10 内容を大幅に修正しました。

今日の小ネタ 180728

本日の気づきシリーズとか作ったら軽いネタも気軽にアウトプットできるのではという目論見です。自分のブログですし。

thunderbirdの小ネタ

  • メールのアーカイブは受信トレイでメールをクリックしてAキー。作ったフォルダには分類できないけど大事なメールが来た時に使う。

  • メール送信時の表の作成について。中に文字を打ってる間にセルの大きさが自動で調整されていくので、勝手にきれいな表が作れるしエクセルみたいにセルを引っ張らなくて済む。これ知らなくて3分くらい引っ張ってた。

 

エンジニアさんのブログを発見した

ブロックチェーンエンジニアとして生きる - ブロックチェーン,エンジニア,ビットコイン,Bitcoin,イーサリアム,Ethereum,暗号通貨,仮想通貨,DApps

ブログは質より量派の方がいらっしゃったようで少し安心。。。どうでもいいけどこのwordpressのテーマ持ってます、使いやすいんですよね

 

椅子でできる筋トレについて

【オフィス&自宅で】イスを使った20種類の筋トレメニューで引き締める! | 【舞筋道-maikindo-】ダンス×筋トレ×ダイエット

体力を戻すために運動はしたいけど進捗も出したい。器具買うほど筋トレは興味ない。気分が乗った時だけでいい…という方におすすめ。最後のほうはオフィスでやっちゃだめ。

 

pseudoの意味は「疑似」とか「偽」

読み方:pseudo: UNIX/Linuxの部屋

すーど、とか、しゅーど、とかいうらしい。pseudo terminal は「疑似端末」っていう意味。linuxいじってるとよく見るんだけど???ってなることがよくあるので。

 

BGPツールキット

Hurricane Electric BGP Toolkit

自分がアクセスしているプロバイダのASがいくつなのかとかが分かります。逆にAS番号から企業を検索することもできます。ピアリングの状態も確認できるのでネットワーク勉強してる人は見ていて楽しいと思います。

 

ps aux したときの [hogehoge/0] って何

タイトルを迷って非常に抽象的にしてしまいましたが、CLIが固まってしまってデバッグしてた時の調べものです。

カーネルスレッド

[hogehoge/0]のように[]で囲われたプロセスはカーネルスレッドと呼ばれます。

カーネルスレッドとは - Linuxの備忘録とか・・・(目次へ)

f:id:frazz:20180512182616p:plain

カーネルスレッドの役割はワークキュー、メモリの回収、ソフト割込みなどで、カーネルの動作を補助するものになっています。ここでカーネル起動時にinit (process ID 1)が生成されると、それを親にして子プロセスが生成される。。。という話あたりもしたかったのですが、こちらに詳細があります。気が向いたら追記します。

カーネルスレッド生成&ユーザーモードプロセス生成 - Qiita

で、カーネルスレッドとユーザプロセス、psコマンドで両方見ることができるのはなぜかというと、スケジューリングの観点から見たときカーネルスレッドもプロセスも同じ手順(do_fork関数)で生成されるからなんですね。


ただ違いももちろんあって、一般的なプロセスは生成されるときに一定のメモリ量を割り当てられるので、メモリの限界が来ない限り同時にたくさんのプロセスを抱えることができます。それに対しカーネルスレッドも同時にたくさん動作することは可能なのですが、その上限はハードウェアのメモリ量ではありません。「カーネルスレッドを動かすプロセスに割り当てられたメモリ量」です。

なので、リソース確認用コマンドで確認してもメモリがいっぱいになっていないのに動作が重くなる、あるいはロードアベレージが高くなる場合はカーネルスレッドが乱立しているかもしれません。その場合のデバッグはケースバイケースなんでしょうけど、自分が躓いたときは一緒に動いている他のサーバがトリガーになってました。nfsの挙動がおかしくなっているのをdmesgコマンドで見つけた感じです。

なかみ

まだ整合性に欠ける表現があります。

  • [events]

非同期実行の必要がある低レベルの要求を処理するメカニズム

  • [kintegrityd]

ワークキュー?ブロックデバイスに誤りがないかチェック

  • [kblockd]

カーネルのブロックI/Oタスク

  • [watchdog]

時間ごとに監視するやつ、途切れたらアラートを上げる

  • [stopper]

カーネルマイグレーションスレッドともよばれる

  • [ksoftirqd]

ソフトウェア割込みが高いと実行される

  • [xfsなんとかd]

"xfsファイルシステムは処理効率のための動作タイミングを正確に制御する必要があるカーネル機能の一つである" とりあえずxfsはファイルシステム

  • [rpciod]

NFSと関係があるらしい