Cybozu Tech Conference 2016 バグの調べ方
4. • サイボウズの研究開発部門 • 次世代の製品・サービスの基盤となる技術を 中長期視点で研究開発する • 私 • 主にセキュリティ関係に関わる • https://github.com/herumi/ • サブでcybozu.comのバックアップレプリケーションシステム • ＋ たまにやってくる不具合調査 サイボウズ・ラボ 4 / 29 5. • https://github.com/herumi/mcl • 汎用楕円曲線・ペアリング暗号ライブラリ • https://github.com/herumi/ate-pairing • 世界最速実装の一つ（IEEE Trans. on Computers, 2015） • 何に使うの? • 『クラウドを支えるこれからの暗号技術』 をご覧ください • 例：完全匿名可能な分散型暗号通貨 Zcashのゼロ知識証明プロトコル ペアリング暗号の実装
特定条件下の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
革命の日々！ 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」変更は無意味？
小崎 資広 (KOSAKI Motohiro) @kosaki55tea . @sonots から日本のWeb界隈ではTCP_TIMEWAIT_LEN を変更してカーネルリコンパイルがデファクトという話を聞いて軽くぐぐってみたところ、たしかに大量にそのようなページがヒットする。しかもどれ一つとして理由が書いてない。そして日本特有の現象 小崎 資広 (KOSAKI Motohiro) @kosaki55tea 軽くソースを見た感じだと、tcp_tw_reuse をセットすると１秒で TIME_WAITのsocketは再利用が始まるので、いまひとつリコンパイルの必要性が分からず。これ、ソース呼んで妥当性チェックした人がいるノウハウなのかなあ
Linux container update
2. Who am I • Linux メモリ管理コア開発者 • MM Summit(上位20人のコア開発者会議）５ 年連続招待 • Ruby core committer • コミット率TOP10コミッタのうちの一人 • ボストン在住、Red Hat常駐 • Herokuは使ったことがありません 4. What is Container • むつかしい言い方をすると Operating system– level virtualization • FreeBSD jail が嚆矢 • Containerという用語を最初に使い始めたの はSolaris • リソース(CPU, memory, IO, etc)の分離 + 名前 空間(pid, IP adress, chroot)の分離 + (SELinux) • ここ二年ぐらいで急速に注目度アップ 5. Linux v2.6.32 • 20
Heroku meetup に行って来た。 #herokujp - 未来のいつか/hyoshiokの日記
Heroku Meetup #12 恋に落ちるときはいつもハッピー - Japan Heroku User Group | Doorkeeper 渋谷は豪雨。雷ぴかぴかごろごろ。 がちゃぴん先生のLinuxの最近の動向と最近なにかと話題のコンテナについての概説。わかりやすくてよかった。 まさかHeroku meetupでLinuxの話を聞けるとは思わなかった。 次回のカーネル読書会もDockerのお話なので、興味ある人は来るといいと思うよ。 Kernel Code Reading Party 111th; 第111回、カーネル読書会 #ylug_111 - Kernel Code Reading Party (YLUG), カーネル読書会 | Doorkeeper 六厘舎 おなかがすいたので、ミートアップの前に、大崎で最近開店した六厘舎でつけ麺を食った。昔あった本店は休業中。特に人が並ぶと
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
新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 における時間
RHEL(CentOS)6系でトラフィックをたくさん捌くサーバが死ぬ問題は6.5のkernel-2.6.32-431.el6以降で多分直る - このブログはURLが変更になりました
タイトルで言いたいことはすべて言った。 経緯 うちの場合はLVS+keepalivedなロードバランサなんだけど、ちょくちょくkernel panicになる問題が発生してた。 そこでcrashコマンドで解析してみた。crashコマンドの使い方はこちらが参考になる。Linux crash dump 読み方入門 # crash /boot/System.map-2.6.32-279.14.1.el6.x86_64 /usr/lib/debug/lib/modules/2.6.32-279.14.1.el6.x86_64/vmlinux /var/crash/127.0.0.1-2013-09-27-16\:21\:01/vmcore (snip) SYSTEM MAP: /boot/System.map-2.6.32-279.14.1.el6.x86_64 DEBUG KERNEL: /usr
kernelをチューニングしてTIME_WAIT値を変更する - メモとかそんな感じなやつ
kernelのチューニングについて まぁ個人的な所感なんですけど。。 10年前ぐらい前、とあるシステムで原因のリンクダウンが頻発するトラブルがあり、まったく原因がわからなかったのですが、当時の先輩がkernelのソースコードをいじくって直したことがありました(なんかパッチ送ってました)。 私はその頃ペーペーだったのですが、なにこの変態と思いつつも、その技術力にとても感動しました。 10年たった今はだいぶ安定しておりkernelレベルのチューニングはあまり必要性を感じていませんが、どうしてもって時はこうやるよって感じのメモです。 まぁTIME_WAIT値を変えるぐらいなら大したことないんですけどね。あのリンクダウンってどうやって解決したのかな。10年たった今でもさっぱりわからん。変態め 環境等 OS: CentOS 5.8 (64bit) kernel: kernel-2.6.18-308
CentOS 6.2 で RPS/RFS を使ってネットワークの割り込み処理を複数コアに分散してみた - blog.nomadscafe.jp
以前(2010年)に「アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件」というエントリにてCPUのコアが増えても割り込み処理が分散されないのでスケールされないと書いたけど、その後Linux KernelにRPS/RFSなる機能が追加され、割り込み処理が分散できるようになり、CentOS 6.2 でも使えるらしいので試してみました。 RPS/RFSについての紹介は VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました http://d.hatena.ne.jp/syuu1228/20110722/1311322653 Linux内核 RPS/RFS功能详细测试分析 http://www.igigo.net/archives/204 が詳しい。2番目のはほぼ読めないけど、性能比較のグラフが分かりやすい。 今回試したサーバは、 OS: C
CentOS5でもRPS/RFSでNICが捗る話 | Nekoya press
kazeburoさんがCentOS6.2での事例を紹介されていますが、CentOS5系でもkernelを上げればRPS/RFSが使えるようになって、NICの負荷状況が劇的に改善します。 やり方は意外に簡単で、ELRepoからkernel-ml-2.6.35-14.2.el5.elrepo.x86_64.rpmを落としてきてインストール。 あとは、/boot/grub/menu.lstの設定をdefault=0にしてrebootすればOK。 $ uname -r 2.6.35-14.2.el5.elrepo ELRepoはNICのドライバなんかもいろいろ提供してくれるし、古いバージョンのRPMをarchiveで提供してくれて非常にいいですね（kernelの過去RPMはないのかな）。 RPS/RFSを有効にする設定はCentOS6と同様です。 # echo "f" > /sys/class/n
うるう秒のLinuxへの影響(2012年7月版) - cuspy diary
2012年7月1日 08:59:59 秒(JST)の後に1秒が追加される、うるう秒が発生しま す。 うるう秒に関する基本的な情報は以下のNICTのページで説明されています。 うるう秒の対応（２０１２年７月実施版） このうるう秒発生時における、Linux上のNTPの動作について検証してみた所、 各種Linuxディストリビューションによって動作が異なる事が解ったのでまとめ てみました。 検証はNICTで公開されている 簡易NTPサーバー を利用して、LIフラグが01のパケットを受け取る方法で行いました。 うるう秒発生時の挙動として以下3種類のパターンが挙げられます。 kernelの機能を利用して時刻の補正を行う LIパケット受信時、ntpdはシステムコールの adjtimex(2) を発行し、kernelの機能を利用して時刻の調整を行います。結果として、 うるう秒発生時に時間の逆行が発生します
クラッシュダンプからカーネルメッセージを取り出すツール「crashdmesg」を作りました : DSAS開発者の部屋
Linuxカーネルには、カーネルパニック時にkexecを使ってダンプ取得用のカーネル(セカンドカーネル)を起動する仕組みがあります。 このセカンドカーネルは予めリザーブされたメモリ内で起動するため、クラッシュしたカーネルが処理していたメモリの内容はそのまま残っていて、procファイルシステム経由でクラッシュダンプを取得する事ができます。 このDSASブログでも、以前「Linuxでクラッシュダンプを採取(1) 〜 kexec + kdump を使ってみる 〜」と言うタイトルでクラッシュダンプの取得方法をご紹介しました。 「crashdmesg」は、kexec+kdumpで保存したクラッシュダンプから、カーネルメッセージの内容を取り出すツールです。 デバッガと比べてはるかに軽量なため、セカンドカーネル上で直接/proc/vmcoreからカーネルメッセージを取り出すこともできます。 最近のクラッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The 67th Yokohama kernel reading party