ぜんぶTIME_WAITのせいだ！ - Qiita
課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39
Linuxカーネルの新機能 XDP (eXpress Data Path) を触ってみる - yunazuno.log
先日netdev 1.2に参加してみたところ，XDP(eXpress Data Path)の話題で持ち切りといった感じだった． というわけで，XDPについて一通り調べつつ，実際に触ってみた． XDPとは何か？ 誤解を恐れずに一言で言うと，「Intel DPDKのような高速パケット処理基盤をLinuxカーネル自身が用意したもの」であると理解している．このスライドでは A programmable, high performance, specialized application, packet processor in the Linux networking data path と言っている． DPDKはユーザランドアプリケーションがNICを直接叩く(=カーネルのネットワークスタックをバイパスする)ことで高速処理を実現している．一方XDPは，カーネル内の最もNICドライバに近い場所でフッ
VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました - syuu1228's blog
はじめに 第一回カーネル／VM探検隊＠関西、第二回日本Vyattaユーザ会ミーティングで行った発表のダイジェスト版です。 詳しく知りたい人はこちらの内容ではなく、第二回日本Vyattaユーザ会ミーティングの動画、資料をみる事をお勧めします。 あと、最新って書いてあるけど割と古い話題です。すんません。 発表資料 従来型のNICとネットワークスタックの組み合わせでは、マルチコア環境においても１つのNICの受信処理は１つのCPUでしか行えません。 これは、NIC上に受信のキューと受信を通知する割り込みが１つしか存在せず、ハードウェアからデバイスドライバまでのレイヤーでは受信処理を並列に行う事が本質的に出来ない事が原因でした。 これが原因で、通信量が多い時にパケット処理の負荷が特定のCPUへ偏ってしまい、CPU数を増やしても性能がスケールしないという問題が発生します。 この問題を解決する為に、１つ
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
1.カーネルとカーネルモジュール(第1章カーネル:基本管理コースII)
ドライバなどカーネルに組み込まれる機能をモジュール化したもの カーネルがコンパクトになっている 動作中のカーネルに組み込むことが可能 ドライバのアップデートにモジュール単位で対応できる ハードウェア構成が変わってもカーネル再構成を必要としない カーネルモジュール カーネルモジュールとは、カーネルの機能を拡張するためのバイナリファイルです。 カーネルモジュールの代表的なものとしては、ディスク、ネットワークカード等をLinuxカーネルで使用可能にするためのデバイスドライバがあげられます。このデバイスドライバは、基本的には、各ハードウェアベンダから提供されるもので、これを使用することによって、Linuxカーネルは、多種多様なハードウェアに対応することが可能になっています。 初期のUNIX系OSでは、カーネルの機能を拡張する場合、デバイスドライバなどはすべてカーネルに組み込むという設計になっていま
第82回 Linuxの成長過程をふりかえる［その1］ | gihyo.jp
1.0以前のバージョンはwww.kernel.orgにもまばらにしか残っていないため正確ではないものの、集計すると過去25年間に1800近い回数のリリースが行なわれていたことになります。さて、それではこれだけのバージョン・アップでLinuxはどのように成長してきたのでしょう？ 1991年に公開されたlinux-0.01のソースコードを調べると、ファイル数は88、総行数は10239行でした。一方、最新版のlinux-4.6ではファイル数が53637、総行数は2120万行を超えています。すなわち、ソースコードのファイル数では600倍強、行数では2000倍強にまで増加していることになります。 Linuxの最初のバージョンと最新のバージョンを比較するとこれほど大きな違いになるものの、ではその途中経過はどうなのか、もう少し詳しく調べてみることにしました。 カーネルサイズの経時的変化 ソフトウェアの規
Linuxカーネルのコマンドラインはブートローダーからどう渡されるのか？ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
先日参加した自作OSもくもく会で「Linuxカーネルのコマンドラインはブートローダーからどう渡されるのか？」のような話が聞こえたので、調べようと思い調べてみました。確認はLinux kernel v4.5とsystemd-bootの2016/05/02 23:00 JSTのコードです。 uefiじゃない環境も確認しようかなと思ってgrubのコードをgit cloneはしました。が、うちのメイン環境で使っているのはsystemd-bootだしってことで確認してません。 で、カーネルのコマンドラインは↓のようなやつですね。 masami@saga:~/codes$ cat /proc/cmdline initrd=\initramfs-4.6.0-rc5-ktest+.img root=/dev/sda2 rw crashkernel=256M コマンドラインをカーネルに渡すとしたら、どこかし
Introduction · Linux Inside
linux-insides A book-in-progress about the linux kernel and its insides. The goal is simple - to share my modest knowledge about the insides of the linux kernel and help people who are interested in linux kernel insides, and other low-level subject matter. Feel free to go through the book Start here Questions/Suggestions: Feel free about any questions or suggestions by pinging me at twitter @0xAX,
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 Insides : カーネル起動プロセス part1 | POSTD
ブートローダからカーネルまで これまでの私の ブログ投稿 を読まれた方はご存じかと思いますが、しばらく前から低水準言語を使うようになりました。Linux用x86_64アセンブリ言語プログラミングについても書いています。また、同時にLinuxのソースコードにも触れるようになりました。下層がどのように機能しているのか、コンピュータでプログラムがどのように実行されるのか、どのようにメモリに配置されるのか、カーネルがどのように処理や記憶をするのか、下層でネットワークスタックがどのように動くのかなどなど、多くのことを理解しようと意欲が湧いています。これをきっかけに、 x86_64 版Linuxカーネルについてシリーズを書いてみようと思いました。 私はプロのカーネルプログラマではないことと、仕事でもカーネルのコードを書いていないことをご了承ください。個人的な趣味です。私は下層で何が起きているのかとても
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - 0xAX/linux-insides: A little bit about a linux kernel