タグ

linuxとkernelに関するtknzkのブックマーク (8)

  • 特定条件下のclone(2)を4倍速くする - 人間とウェブの未来

    とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。 そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo

    特定条件下のclone(2)を4倍速くする - 人間とウェブの未来
  • 革命の日々! Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味? の件について

    なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。 きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://togetter.com/li/871768 以下のように、スラドに転載されてしまったわけだ。 スラド: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://linux.srad.jp/story/15/09/09/0648258/ いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。 tcp_tw_inter

    革命の日々! Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味? の件について
  • Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?

    小崎 資広 (KOSAKI Motohiro) @kosaki55tea . @sonots から日のWeb界隈ではTCP_TIMEWAIT_LEN を変更してカーネルリコンパイルがデファクトという話を聞いて軽くぐぐってみたところ、たしかに大量にそのようなページがヒットする。しかもどれ一つとして理由が書いてない。そして日特有の現象 小崎 資広 (KOSAKI Motohiro) @kosaki55tea 軽くソースを見た感じだと、tcp_tw_reuse をセットすると1秒で TIME_WAITのsocketは再利用が始まるので、いまひとつリコンパイルの必要性が分からず。これ、ソース呼んで妥当性チェックした人がいるノウハウなのかなあ

    Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?
  • Linux container update

    script(src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js") script(src="https://cdn.socket.io/socket.io-1.4.5.js")

    Linux container update
  • Linus様がSystemdにぶちきれる

    systemdは、/proc/cmdlineをパースして、もし、その中に"debug"という文字列を発見した場合、大量の冗長なデバッグメッセージをdmsegに出力する。これは様々な問題を引き起こす。まず、"debug"というあまりに一般的すぎる文字列に勝手に反応してしまうことがひとつ。dmseg、すなわちカーネルのリングバッファーをsystemdの冗長なデバッグメッセージだけで溢れ返させてしまうことがひとつ。そして、なぜかLinuxカーネルのブートに失敗してしまうことがひとつ。 Bug 76935 – Do not parse "debug" command line parameter カーネルコマンドラインに"debug"を与えると、systemdによりパースされる。適当なassertに引っかかると、こんな風にぶっ放される。 [ 150.308000] systemd-journald

  • The 67th Yokohama kernel reading party

    Explaining glibc malloc internals. slide: http://www.slideshare.net/kosaki55tea/glibc-malloc

    The 67th Yokohama kernel reading party
  • kernelをチューニングしてTIME_WAIT値を変更する - メモとかそんな感じなやつ

    kernelのチューニングについて まぁ個人的な所感なんですけど。。 10年前ぐらい前、とあるシステムで原因のリンクダウンが頻発するトラブルがあり、まったく原因がわからなかったのですが、当時の先輩がkernelのソースコードをいじくって直したことがありました(なんかパッチ送ってました)。 私はその頃ペーペーだったのですが、なにこの変態と思いつつも、その技術力にとても感動しました。 10年たった今はだいぶ安定しておりkernelレベルのチューニングはあまり必要性を感じていませんが、どうしてもって時はこうやるよって感じのメモです。 まぁTIME_WAIT値を変えるぐらいなら大したことないんですけどね。あのリンクダウンってどうやって解決したのかな。10年たった今でもさっぱりわからん。変態め 環境等 OS: CentOS 5.8 (64bit) kernel: kernel-2.6.18-308

    kernelをチューニングしてTIME_WAIT値を変更する - メモとかそんな感じなやつ
  • うるう秒のLinuxへの影響(2012年7月版) - cuspy diary

    2012年7月1日 08:59:59 秒(JST)の後に1秒が追加される、うるう秒が発生しま す。 うるう秒に関する基的な情報は以下のNICTのページで説明されています。 うるう秒の対応(2012年7月実施版) このうるう秒発生時における、Linux上のNTPの動作について検証してみた所、 各種Linuxディストリビューションによって動作が異なる事が解ったのでまとめ てみました。 検証はNICTで公開されている 簡易NTPサーバー を利用して、LIフラグが01のパケットを受け取る方法で行いました。 うるう秒発生時の挙動として以下3種類のパターンが挙げられます。 kernelの機能を利用して時刻の補正を行う LIパケット受信時、ntpdはシステムコールの adjtimex(2) を発行し、kernelの機能を利用して時刻の調整を行います。結果として、 うるう秒発生時に時間の逆行が発生します

  • 1