vm.min_free_kbytes からの wmark_{min|low|high} 算出式 - ablog
Linux のページ回収の閾値である wmark_min、wmark_low、wmark_high の算出式を調べたメモ。 算出式 正確には NUMA ノードの ZONE 毎に計算されるが、合計の概算は下記の式で計算できる。 min_free_kbytes = sqrt(物理メモリサイズ(KB) * 16) wmark_min = min_free_kbytes wmark_low = wmark_min + (wmark_min / 4) wmark_high = wmark_min + (wmark_min / 2) 具体例 例えば、x86_64 で物理メモリサイズが 16GB の場合、以下のようになる。 min_free_kbytes = sqrt(16,777,216KB * 16) = 16,384 KB wmark_min = 16,384 KB wmark_low = 16,
strace でプログラムの動きを追ってみよう | SIOS Tech. Lab
◆ エンジニア業務環境アンケート結果 ◆ エンジニアが自分の働き方にどういったことで満足していて、不満を感じているのか、働きたい会社像として何を求めているのか、業務環境調査を実施しました。ぜひご覧ください。 ⇒ アンケート結果はこちらから こんにちは。サイオステクノロジーの貝野です。 プログラム (特定のプロセス) があるひとつの処理を実行する際、内部的にどのような処理がどのような順序で実行されているのか確認したい場合があると思います。 しかし、ログファイルからは詳細な処理内容が確認できない場合も多いです。 このような時、strace というデバッグツールを使用する方法があります。 strace は、特定プロセスのシステムコールレベルでの処理をトレースできるツールです。 今回は、strace コマンドの実行例を元に、実行結果の見方や主なシステムコールについてご紹介します。 strace コ
Linuxがブートするまで
普段Linuxを使っていながら、vmlinuzやinitrd.imgというファイルは何なのか、 あやふやにしか理解していなかったので、一通りLinuxマシンのブートの仕組みを 勉強してみた結果を書き留めておく。なお、BIOSとGRUB Legacyの環境を前提としている。 EFIやGRUB2を使った環境については、今後いずれ勉強していきたい。 基本的にOSの起動は、単純・低機能なプログラムが、より複雑・高機能なプログラムを 読み込み起動するという処理を連鎖的に行う仕組みになっている。 Linuxでは、下記のプログラムが順に起動していく: BIOSブートローダ (GRUB)Stage 1Stage 1.5Stage 2LinuxカーネルInit以下では、それぞれのプログラムについて順に要約して述べていく。 1. BIOS現在一般的なx86/x86-64 CPUは、電源が投入されると、0xff
freeの出力が大幅改善された話
最近freeコマンドを叩くとこんな感じで出力されます。 $ free total used free shared buff/cache available Mem: 20209620 3859396 6594188 502492 9756036 15323144 Swap: 32767996 0 32767996 availableってなんでしょう? そして -/+ buffers/cache の行がなくなっています。 その背景をちらっと紹介します。 最近linuxの3.14で/proc/meminfo に MemAvailable というフィールドが追加されました。RHEL7.0や6.6にもバックポートされています。(RHEL6.6では互換性に配慮してデフォルトではdisableされています) http://git.kernel.org/cgit/linux/kernel/git/to
Linuxカーネルを読む前にやったこと - komukomo’s diary
「カーネルのコードがよくわからない。Linuxカーネルに関する本を読んでもいまいちしっくりこない。」 から、「読めば理解できそう..!」 になるまでにやったことのまとめ。 はじめに 低レイヤの話がわかるようになりたかった。 カーネルの中身が知りたかった。 とりあえず本を読もうと思い詳解 Linuxカーネル 第3版を読んだが知識がなさ過ぎてよくわからない。 知らない用語だらけで都度調べればなんとなくはわかる気もするが、いまいち頭に入ってこない。 今思うとそもそもCPUの話なのかカーネルの話なのかさえよくわからない状態で読んでいたような気がする。 そんな状態を克服するためにやったことをまとめておく。 学習前 学習前の自分の知識はこんな感じだった。 知っていた データ構造とアルゴリズム 論理回路 C言語（研究室で数値計算に使える程度。構造体やポインタくらいならわかる。） よく知らなかった OSが
超高速なパケットI/Oフレームワーク netmap について - ゆううきブログ
GPUを用いたSSLリバースプロキシの実装について - ゆううきブログ 100Gbpsソフトウェアルータの実現可能性に関する論文 - ゆううきブログ の続きで，最近論文読んだやつのプロジェクトの紹介です． 概要 今の汎用OSは高速なパケットI/Oを考慮してない． 20年前のAPIをそのまま使っている． ネットワークがどんどん高速になっているので，NICとかOSカーネルのパケット処理がボトルネックになってる． (http://news.mynavi.jp/news/2013/04/04/094/index.html) こういうの解決するために既存手法がいろいろある． Linux packet mmap - IwzWiki Linux Kernel Documentation :: networking : packet_mmap.txt DNA (Direct NIC Access) Pac
Glibc malloc internal
glibc mallocの解説 Video: https://youtu.be/0-vWT-t0UHgRead less
Linux のページ回収まわりのカーネルパラメータ - ablog
Linux(kernel 2.6.32-303 以降)のDBサーバでメモリ16GB、スワップ領域16GBの場合、ざっくりこんな感じが良いかなという妄想メモ。 vm.swapiness=1 vm.overcommit_memory=2 vm.overcommit_ratio=80 vm.min_free_kbytes=524288 vm.extra_free_kbytes=1048576(kernel 3.5以降) vm.swappiness=1 でページアウトよりページキャッシュ解放を優先させる。kernel 2.6.32-303 以降、0 にすると OOM Killer が発動しやすくなるらしいので、1 にする。 vm.overcommit_memory=2 でオーバーコミットしないようにして、OOM Killer が発動しにくくする vm.overcommit_ratio=80 で仮想
RHEL6.4(kernel 2.6.32-303)以降の vm.swappiness=0 と OOM Killer の関係 - ablog
RHEL6.4(kernel 2.6.32-303)以降、vm.swappiness=0 にすると OOM Killer が発動しやすくなるので、1 にしましょうという話を見かけるのでメモ。詳しくは後日調べる予定。 Deploying Oracle Database 12c on Red Hat Enterprise Linux 6 Best Practices Warning: Since Red Hat Enterprise Linux 6.4, setting swappiness to 0 will even more aggressively avoid swapping out, which increases the risk of out-of-memory (OOM) killing under strong memory and I/O pressure. To ach
Linux: Tuning Swappiness | KernelTrap
A number of Linux kernel developers recently debated "swapiness" at length on the lkml, exploring when an application should or should not be swapped out, versus reclaiming memory from the cache. Fortunately a run-time tunable is available through the proc interface for anyone needing to adapt kernel behavior to their own requirements. To tune, simply echo a value from 0 to 100 onto /proc/sys/vm/s
NECを退職し、新会社を立ち上げました。 - KaiGaiの俺メモ
ご報告が遅れましたが、6月30日付で新卒の2003年から14年あまり勤務したNECを退職しました。 また、本日、東京法務局品川出張所においてヘテロDB株式会社の登記申請を行い、また、併せて新会社のチーフアーキテクト兼代表取締役社長に就任しました。 今後は、前職では実現できなかった、GPUやSSDなどヘテロジニアスな計算機資源を活用する事で、高性能、低価格、使いやすさを両立するデータベース製品の事業化を目指していく事になります。 どうぞよろしくお願いいたします。 web: http://heterodb.com/ 弊社が入居する西大井創業支援センター（品川区） 10年以上も勤務した会社を辞めてスタートアップを立ち上げるというのは、おそらく人生の中でも上位に食い込むビッグイベントの一つだと思うので、今の決意や創業に至る一連の流れについて記録を残しておこうと思います。 （書き下してみたら意外と長
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,
Linux スケジューラーのコア実装とシステムコール - Qiita
はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読み始めたきっかけは、スケジューラーのアーキテクチャ、スケジューリングアルゴリズム、スケジューリングアルゴリズムの切り替え方、nice 値やプロセッサアフィニティがスケジューリングに及ぼす影響、プリエンプションの流れ、マルチプロセッサにおけるタスクのロードバラ
runtime.js – JavaScript library operating system for the cloud
Overview runtime.js is an open-source library operating system (unikernel) for the cloud that runs JavaScript, can be bundled up with an application and deployed as a lightweight and immutable VM image. It's built on V8 JavaScript engine and uses event-driven and non-blocking I/O model inspired by Node.js. At the moment KVM is the only supported hypervisor. It tries to be compatible with npm modul
Linux Performance
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
O_DIRECTで遊ぶ - takkan_mのNo planな日常
ここ二日ほど、Linuxをインストールしていたのは、O_DIRECTで遊ぶため。たまには、Linuxでご飯を本当に食べているということを見せようかと。たぶん、間違っている可能性があるので、ご指摘いただけるとうれしいです。一応、参考は、Linxuカーネル解読室のP314あたり。 O_DIRECTというのは、Linuxのカーネル2.4から(だよね)openシステムコールにたてれるようになったI/Oの直接転送を指定するフラグ。 自分が今の部署にはいって、最初に書くことになったTestプログラムで使ってくれとたのまれて、ちょうど一年前ぐらいにもさわっていたんだけど(昔のブログにはかいたんだけど、今そのブログがない）、最近、仕事の空いた時間で、ファイル経由のI/Oアクセスについて、いろいろ勉強(主にオライリーのカーネル本を読んでいる)していて、昔より何やってるいるかわかったきがするので、ちょっと遊ん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://slacknotebook.com/linux-io-scheduler1/?s=09
http://www.makelinux.net/kernel_map/
Linux source code (v6.8) - Bootlin