SegmentSmack and FragmentSmack: IP fragments and TCP segments with random offsets may cause a remote denial of service [CVE-2018-5390, CVE-2018-5391] - Red Hat Customer Portal![SegmentSmack and FragmentSmack: IP fragments and TCP segments with random offsets may cause a remote denial of service [CVE-2018-5390, CVE-2018-5391] - Red Hat Customer Portal](https://cdn-ak-scissors.b.st-hatena.com/image/square/3108d3d39d44b30ca4891c7cf9161910927d3fdb/height=288;version=1;width=512/https%3A%2F%2Faccess.redhat.com%2Fwebassets%2Favalon%2Fg%2Fshadowman-200.png)
Amazon Linux 2017.03で新しいTCP輻輳制御アルゴリズムBBRを試してみた | DevelopersIO
ども、大瀧です。 AWSが提供するLinuxディストリビューション Amazon Linuxの最新版であるAmazon Linux 2017.03がリリースされました。このリリースで採用しているLinuxカーネル バージョン4.9では、新しいTCP輻輳制御アルゴリズムBBRのサポートが追加されています。 しかしながらAmazon Linux 2017.03.0のカーネルパッケージではBBRモジュールが無効なため、今回はカーネルを再ビルドして試す手順をご紹介してみたいと思います。 お断り : 一般的にカーネルを再ビルドして利用することはディストリビュータのサポート範囲外になります。自己責任の元、検証用途にとどめ本番環境への適用はビルド済みカーネルパッケージのリリースを待ちましょう。 ビルド環境の準備 まずは、カーネルを再ビルドするための環境を整えましょう。一般的にカーネルの再ビルドにはローカ
特定条件下の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 I/O のお話 write 編 - naoyaのはてなダイアリー
write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、本当にそうなんでしょうか？（否定しているわけではなく、純粋な疑問です。） と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネル本の 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方
アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog
問題 アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について調べた。 該当のサーバでは、以下のようにメモリの使用率が徐々に上昇していく。 また、アプリケーションのプロセス自体がメモリを消費しているわけではない状態。 原因 調査すると、このバグ仕様を踏んでいるのではないかと思われるページを見つけた。 https://bugzilla.redhat.com/show_bug.cgi?id=1044666 内容としては、curlを実行した際に /etc/pki/nssdb/以下の存在しないファイル(毎回違うパス)に対してaccessシステムコールが大量にコールされ、 negative dentry cacheが溜まっていき、メモリ使用量が圧迫されるというもの。 実際、この状況が起きているサーバを調べるとメモリ使用率のうち多くを占めているのはnega
/proc/meminfoを考える - めもめも
通りすがりの貴方・・・・ /proc/meminfoのあっちの値とこっちの値を足したら、なんでそっちの値と同じにならないの・・・・ と悩んだことありますよね？ /proc/meminfoは、カーネルが内部的に管理している枠組みでのメモリ情報をそのまま出しているので、残念ながらユーザ視点で知りたいメモリ情報とは一致しません。 とはいえ、変な解釈をして無意味に悩まないために、それぞれの値の意味合いと項目間の関係を知っておくのは有意義です。私の理解の範囲で、それらの関係をまとめていきます。 ＃私の理解も完璧ではないので、間違いあればやさしくご指摘お願いします。 参考資料 http://mkosaki.blog46.fc2.com/blog-entry-1007.html 2011/09/07 追記： tmpfsがSwapCachedに含まれるのは幻想でした。tmpfs=Shmemに修正しました。
Linuxカーネルを2038年問題に対応させるには
System call conversion for year 2038 [LWN.net] lwn.netでLinuxカーネルを2038年問題に対応させるにはという記事が公開されている。 32bit版Linuxカーネルのtime_tはsigned 32 bitなので、現行の32bit版Linuxカーネルをそのまま使い続けるシステムは、2038年問題の影響を受ける。 問題の日付が近づくにつれ、32bitシステムは様々な楽しげな理由により障害を起こすことが予測されるので、今日のLWN読者は、退職から呼び戻されて、紀南を救うために英雄的な活躍をするだろう。今対策をしなければの話だが。 さて、32bit Linuxカーネルでも、time_tなどの時間の表現に64bitの値を使えば2038年問題は解決できるか。実は、問題はそれほど単純ではない。 カーネル内部の時間表現を64bitに移行するだけでは
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分ごとのシ
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Buffer I/O error on device fd0, logical block 0 error and simply soultion
PID1 は、カーネルから
特別扱いされてるって本当ですか？