【お知らせ】メモリ枯渇時の挙動の安定性が改善された Linux カーネル 4.15 が公開されました | NTTデータ先端技術株式会社
Tweet お知らせ - 2018.02.22 Linux カーネルはメモリが枯渇した際の挙動を十分に考慮しておらず、メモリの枯渇が原因でLinux システムがハングアップしてしまうことがあるという問題があります。 この問題に当社ソリューション事業部 半田 哲夫が4年半取り組み続けた結果、メモリの枯渇時にハングアップしてしまう処理の多くが修正されました。現時点までの道のりは、以下の資料／動画でご覧いただけます。 資料：https://elinux.org/images/7/73/CELFJP-Jamboree63-handa-ja.pdf（社外サイト） 動画：https://youtu.be/ZznEyf1PN0Q（社外サイト）
net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
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
小さいLinux環境の作り方
小さいLinux環境の作り方 Presentation Transcript 小さい Linux環境の 作り方 Naomasa Matsubayashi 保存するアイコン フロッピーディスク 2000年代初頭 フロッピーディスクに必要な物が全部入った Linuxディストリビューションが流行った floppix http://floppix.com/ HAL91 http://chris.silmor.de/hal91/ tomsrtbt http://www.toms.net/rb/ 3.5インチフロッピーディスクの容量 1D 2D 1DD(Mac) 1DD 2DD(Mac) 2DD(PC-98) 2DD 2HD(PC-98) 2HD(PC/AT,Mac) 2ED 2TD 160KiB 360KiB 400KiB 360KiB 800KiB 640KiB 720KiB 1232KiB 1440
TIME_WAIT状態のTCPコネクションを早く終了させるべくKernelをリビルド - 元RX-7乗りの適当な日々
以前、一度やったはずなのですが、すっかり忘れてしまっていて、結局調べることになったので、今回はここに作業ログを残しておきます。 TIME_WAITコネクションの増殖 一般的にネットワークアクセス数が極端に多いサーバでは、TIME_WAIT状態のコネクションが残留しがちです。 TIME_WAITの滞留時間が、Linuxデフォだと60秒になっているため、下記のエントリにも書きましたが、60秒の間に数十万レベルのリクエストが来るとあっという間にコネクションテーブルが埋まっていってしまうわけです。 で、別にTIME_WAITコネクションが多くなってしまうこと自体は、完全な悪というわけでもなく、 "net.ipv4.tcp_max_tw_buckets" あたりでキャップもできるし、それなりに制御して付き合っていけばいいわけですが、ローカルのTCPポートを使い切るようなケースだと、使えるローカルポー
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
mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog
こんにちは。年末と年度末になるとブログを書きたくなる運用部アプリ運用グループの清水です。 気づけば前回の記事から3ヶ月が経過してしまいました… 今回は、ビルド&Kernel編と題して、Fedora 17向けにおこなったパッケージのビルドや、KernelのConfig、TCP周りの変更点について紹介したいと思います。 パッケージのビルド OSが大幅にバージョンアップすると、依存しているライブラリに大きな変更が入ったり、RPMの仕様変更もあるため、Fedora 8時代のパッケージのリビルドなど、多くのRPMパッケージを作りなおさなければなりません。 mixiでは、Fedora標準パッケージとは別に150個以上のパッケージを、 configureなどビルドオプションを変える Fedoraで提供されないパッケージを作る ディストリビューションに依存しない構成のパッケージを作る(あとで紹介するPer
カーネルパラメータvm.swappiness によるスワップの最適化 – アプレンティス プラクティス
Linuxでのswap Linuxはメモリが潤沢にある場合でも、頻繁にSwap領域を使うようです。そのSwapする頻度を調節するカーネルパラメータがvm.swappiness（カーネル2.6以上から導入されたパラメータ）です。 用途 データベースサーバなどパフォーマアンスを求められるサーバで、頻繁にスワッピングが発生するのが困る場合などに有用。swapが発生するのを最小限にするために値を0〜10くらいにすると良い。 使用方法 vm.swappinessの値を確認する方法は以下です。値が小さいほうがSwapしにくくなる。つまり、小さくすればするほど物理メモリを使えるだけ使うようになる。0にすると物理メモリを使いきるまでswapしなくなる。 現在のswappinessの値を確認(デフォルト60) # cat /proc/sys/vm/swappiness 60 vm.swappinessの設定
Linuxエンジニア日記 ページキャッシュの効率化
メモリチューニングの一環としてページキャッシュの効率化を纏めてみます。 ちなみにLinuxは空きメモリをがしがしファイルI/O用のキャッシュとして利用しますが、 メモリはページ単位で分割管理されており、これらのキャッシュをページキャッシュと言います。 (これらは使われっぱなしではなく頻繁に割当て、解放が行われています) ではページキャッシュのチューニングとは何をするかと言うと、 要は無駄なページキャッシュを残さないようにしてあげればよいのです。 通常のI/O処理はライトバックで処理されているので、ページキャッシュに書き込まれた時点で プロセスには書き込み完了通知が返され、キャッシュ上のデータはバックグランドでディスクに 書き込まれていきます。 ライトバックしたキャッシュ上のデータは解放可能なデータとなりますので、 頻繁にライトバックをしてあげる事でキャッシュの解放サイクルを早める事が出来ま
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
Isucon用Webサーバーrecaro : DSAS開発者の部屋
11/3に開催された #isucon2 に、隣の席の @pandax381 と一緒に、チーム双龍として参加してきました。 結果は惨敗だったのですが、そのレポートを書く前に、 #isucon2 で使う予定だった秘密兵器 recaro について紹介します。 recaro とは recaro はカーネル空間で動く httpd + memcached サーバーです。 httpd サーバーは @pandax381 が作成した tkhttpd で、 memcached は kmemcached というプロジェクトが 未完成のまま放置されていたのを見つけて、私がデバッグ＆高性能化したものです。 (KLab/kmemcached) 通常のnginx+memcachedだと ネットワーク <- TCP/IP ]-> nginx <-[ TCP/IP ]-> Memcached ([] はシステムコール) と
sched_clock() overflow after 208.5 days in Linux Kernel
えーっと、久しぶりに Linux Kernel にダメダメなバグが発見されて、よりにもよってうちの製品も影響を受けたので、ここに詳細を書くことにした。 つーか。新しい Kernel を使うなら皆で使おうよ。なんだよその「1つだけ」影響を受けて残りは「影響も受けないぐらい古い」ってのは… 概要 大雑把に 208.5日連続運転した Linux Kernel が突如として reboot する。 実機でなおかつ Time Stamp Counter を内包している必要があるので、Pentium4以降のプロセッサ(が、それはようするに今ある Intel 系CPU全部)か、その互換CPUである必要がある。32bit モード、64bit モードの区別はない。 逆に VMware や Xen など、仮想マシン上で動いている kernel に影響はない。これはそもそもバグを内包したルーチンを、仮想マシンで動
Linuxのソースコード管理サイト「kernel.org」が復旧
不正侵入を受けてダウンしていたLinuxカーネルのソースコード管理サイト「kernel.org」が復旧した。同サイトに掲載された告知では「これまでにwww.kernel.orgとgit.kernel.orgが復旧した」と説明している。 Kernel.orgへの不正侵入は8月28日に発覚した。何者かがサーバにroot権限でアクセスしてSSH関連のファイルを改ざんしたほか、システムの起動スクリプトにトロイの木馬が仕込まれて、ユーザーの通信が記録されるなどの被害が発生していた。 今後はさらに数週間かけてkernel.orgの各種システムを復旧させる予定だという。 この情報を伝えたセキュリティ企業Sophosは、ブログでkernel.orgの復旧を歓迎するとしながらも、「伝説的にマルウェアに強いとされたLinuxはどこに？」と問い掛けている。
Linuxのソースコード管理サイトに不正侵入
Linuxカーネルのソースコード管理サイト「kernel.org」は、同サイトのインフラを構成する多数のサーバが不正侵入を受けたことを明らかにした。現時点でソースコードのリポジトリは影響を受けていないと考えられ、それを確認する作業を進めているという。 Kernel.orgによると、不正侵入は8月28日に発覚し、何者かがサーバにroot権限でアクセスしていたことが分かった。侵入には不正に取得したログインIDが使われたとみられるが、どのようにroot権限を取得したかは現在調査中だという。 この攻撃により、SSH関連のファイルが改ざんされ、システムの起動スクリプトにトロイの木馬が仕込まれて、ユーザーの通信が記録されるなどの被害が発生した。 一方でkernel.orgの場合、一般的なソフトウェアのリポジトリに比べてクラッキングによるダメージははるかに少ないとも説明している。Linuxカーネルの開発
Linux カーネル 3.0 リリース | スラド
Googleが自前のサーバ専用ファームウェア処理をコミットしていた件でしょうか。 config GOOGLE_FIRMWARE bool "Google Firmware Drivers" depends on X86 default n help These firmware drivers are used by Google's servers. They are only useful if you are working directly on one of their proprietary servers. If in doubt, say "N". うん、疑いようもなくNを選ばせてもらったよ! ※ よいこのみんな!make-kpkg(kernel-packageパッケージ@Debian)でこのカーネルをビルドすると、 バージョンが3.0.0にされちゃうみたいだぞ(wheez
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
2010年11月18日 "ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード | gihyo.jp
Linux Daily Topics 2010年11月18日"ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード Linus Torvalds氏という人は、少なくともメールの中では、かなりはっきりと感情を表に出す。誰かor何かに対して怒っているときは相手を名指しで批判（というより非難）し、逆にうれしいときはあふれる喜びを隠そうとしない。今回紹介するのは後者のほう。「I'm also very happy」「it is a _huge_ improvement」「Good job.」など、喜びと称賛の表現がたくさん書かれているメールだ。 Linus氏を歓喜させたのは、カーネル開発に携わるMike Galbraith氏が書いた233行のカーネルスケジューリングパッチ。このパッチを適用すると、デスクトップ環境においてパフォーマンスが著しく向上するという。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://linux.mini13i.com/?kernel%2F%A5%B7%A5%B9%A5%C6%A5%E0%A5%D1%A5%E9%A5%E1%A5%BF
http://vps.jp.net/VPS%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0/
http://japan.internet.com/webtech/20110723/1.html