SYNを受け取っているのにSYN-ACKを返さない件 - FLINTERS Engineer's Blog
こんにちは！@kakeyangです！ 久しぶりの投稿です。 なぜなら、、、沖縄の八重山諸島に旅行に行ってましたのです！ 楽しかったなぁ（遠い目） 今回は、開発で経験した通信障害の原因とその対策を公開します。 原因がLinuxカーネルの設定だったので、結構苦労しました。。。 障害概要 異なるネットワーク内（片方は弊社ネットワーク）の物理サーバ間（弊社が受信側）でインターネット越しにソケット通信を行う。 毎回ではないが1割程度の割合で、送信側でconnection timeoutを観測。 受信側にはapacheのログが残っていなかったので、webサーバには届いていない。 送信側でtracerouteすると、確かに弊社ネットワーク内には入っている。 弊社ネットワーク内のF/Wから物理サーバの間のどこかで通信が途絶えているっぽい！ というところまではすぐに判明しました。 調査内容 データセンターと
システムコールを経由する生のLinuxスレッド | POSTD
Linuxのスレッドは、洗練された美しい設計です。スレッドは仮想アドレス空間とファイルディスクリプタテーブルを共有するプロセスに過ぎません。プロセスによって生成されたスレッドは、メイン”スレッドの”親プロセスに追加された子プロセスです。これらは同じプロセス管理のシステムコールを通して処理されるので、スレッドに関するシステムコールのセットを分ける必要性を取り除きます。これはファイルディスクリプタと同様に洗練された方法です。 一般的に、UNIX系のシステムではfork()を使ってプロセスを生成します。新しいプロセスは、オリジナルのコピーとして独自のアドレス空間とファイルディスクリプタテーブルを取得します。（Linuxではコピーオンライトを使用して、この部分を効率的に処理します。）しかし、これは非常に高度なスレッドの生成方法なので、Linuxでは別の clone() システムコールを使用します。
Improving Performance
Many Unix-like operating systems and distributions are tuned for desktop or light use out of the box and not for a production database. This guide describes recommended system performance tunings for operators of new and existing Riak clusters. The tunings present in this guide should be considered as a starting point. It is important to make note of what changes are made and when in order to meas
Linux/arm64のブートプロセスについてのメモ - Qiita
Linuxのブートプロセスを追うときに見るべきファイル(x86_64編)のarm64版のようなもの。 ブートストラップ linux/Documentation/arm64/booting.txt によると、現在のarm64用カーネルは、x86_64用カーネルが持つようなブートストラップの機能が存在しない。実際、arch/arm64/boot/以下にはx86_64のようなソースコード(head_64.S等)が存在しない。ブートローダがハードウェアの最低限の初期化をして、解凍された生のカーネルイメージ(ELFではない)を配置、エントリポイントにジャンプしてやらないといけない。カーネルに実行を移すときの要件も、booting.txtに書かれている。 ブートローダとしては、ubootやUEFIが使えると思われる。(Boot Wrapperというのも使えるみたいだが、今も使えるかは分からない。) a
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
Linux 4.0のリリース候補版が登場。3.20か4.0かを選ぶ投票の結果を受け、Linus Torvalds氏がバージョン4で行くと
「大きい番号は魅力的だからv3.20へ進むか、あるいは番号をリセットしてv4.0にするか、どっちがいい？」。約10日前の2月13に、Linus Torvalds氏は次のLinuxのバージョン番号についてGoogle+に質問を投稿し、投票を呼びかけました。 2.6.39のようなバージョン番号を避けたかった Linux 4.0へとLinuxのメジャーバージョン番号を大きくすることは、以前からTorvalds氏が個人的な希望として示していたことでした。Torvalds氏は投票を呼びかける投稿の中でも「I don't want another 2.6.39」と書いています。これは、2.6.39のようにバージョン番号の下位の細かい数字が増えていくことで、バージョン番号が分かりにくくなることを敬遠したい、ということを示しています。 そして現在のLinuxがバージョン3になり下位の数字が3.19から次に
Linux Kernel Hack入門編 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2014の25日目ですヽ(=´▽`=)ﾉ 今回はLinux Kernel Hack入門編ということで入門的なことを書いてみたいと思います。 まず使用する環境ですけど最近出たばっかのFedora 21のWorkstationにしました。まあ、今回の内容的にはディストリビューションは問わないんですが、多くの人が馴染んでいるであろうfedora系というかパッケージマネージャがyumということでこれにしてみました。 自分は普段Arch Linuxなんですけど、こっちだとkernelのmake install時にちょっとしたスクリプトを書く必要があったりするのもあって、fedoraのほうが手軽かなというのもあります。 カーネルコード・リーディング ブラウザベースでコード・リーディング 読めるソースは大概メインラインのカーネルということになりますが
第8回「カーネルパラメーターチューニングノススメ」 | NTTデータ先端技術株式会社
Tweet 今回は、システムがデッドロックしたり無応答状態に陥ったりしているかもしれない状況を警告する watchdog 系パラメーターについて紹介します。 死活監視ソフトウェアの設定にもよりますが、例えば Pacemaker では、 2 秒間隔で /dev/watchdog への書き込みを行いながら、10秒間（実際には余裕を見て11秒間）書き込みが行われなかった場合に、 /dev/watchdog 発動による再起動が行われる設定になっていることが多いようです。 近年では搭載メモリーが増えてきたことにより、メモリー回収処理が発生した場合の遅延時間も長くなってきるのではないかと思われます。また、仮想化環境では十分な CPU 時間が割り当てられなかったことで処理が遅延し、 /dev/watchdog 発動による再起動が発生しやすくなっているようにも思われます。もしかすると、 10 秒という /
Raspberry Pi Kernel Compilation - eLinux.org
Back to the Hub. Software & Distributions: Software - an overview. Distributions - operating systems and development environments for the Raspberry Pi. Kernel Compilation - advice on compiling a kernel. Performance - measures of the Raspberry Pi's performance. Programming - programming languages that might be used on the Raspberry Pi. Important note The instructions provided below appears to be ou
あるコンテキストスイッチの話
2014年7月5日に行われたOSC名古屋、及び2014年7月12日にカーネル/VM探検隊@北陸 1でのスライドです。 楽しさ求めて、もうちょっとはじけちゃえ(ぴょんぴょんと)
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ
社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。 最近、Graphite に保存しているデータのバックアップ（データ同期）に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。 論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U
Kernel Parameters、Kernelオプション、ブートオプションってどこに書いてあるのか。 - kanonji’s diary
Linuxには*1ブートオプションとかKernelオプションと呼ばれるものがありますが、あまり使うものでも無いので、よく知りません。 ふと、どんなものがあるのか気になって調べてみたら、これが全然情報が出てきません。 メーリングリストとかブログで、何かの問題解決のために、ブートオプションを指定したという記事はあっても、どんなオプションがあるのか一覧になっている情報がなかなか。 結構時間がかかっちゃったけど、いくつか出てきたのでメモしておきます。 まだ全然把握できて無いけど、疑問が出来たときの参照先が分かっただけでも、とりあえずは良いかな。 Ubuntu https://help.ubuntu.com/community/BootOptions Ubuntu DocumentationのCommunity Documentationというカテゴリーの記事です。 ユーザーの投稿によって作られるド
Linuxカーネルハックに興味があるけど特にネタが無いんだよな〜って人向けの小ネタ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of
Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子
Linus Torvalds - Google+ - One of the things I end up doing is do a lot of performance… Linus Torvaldsが、最近のIntelのCPUは、通常以外の処理のコスト、つまりPage faultのコストが上がっているので、問題であるとしている。 俺はよくカーネルコードのパフォーマンスプロファイリングをやる。特に、VMとかファイルシステム周りに対してだ。 俺がよくやるのは、「うまくいってるとき」に対する計測だ。つまり、だいたいほぼ完璧にキャッシュされてる状況だな。というのも、俺はもちろんIOのことは気にかけているが、俺の個人的なワークロードはたいてい、うまくキャッシュされてるからだ。たとえば、俺にとってよくあるロードは、pullした後のフルカーネルビルドだ。これにどのくらいの時間がかかるかが問題になる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
Charming Python: Functional programming in Python, Part 3
How to compile a kernel module for Raspberry pi?
IBM Developer
ARM 64bit has come!
