IAMポリシー"AmazonSSMManagedInstanceCore"を付与したIAMロールをEC2にアタッチする。 AWSマネジメントコンソールにログインして Systems Manager をクリックする。 [セッションの開始]をクリックする。 インスタンスを選択して[セッションの開始]をクリックする。 コマンドラインからシェル操作ができるようになります。 補足 プライベートサブネットのEC2に接続したい場合は以下のVPCエンドポイントを作成する。VPCエンドポイントとEC2のセキュリティグループの設定も要注意。うまく行かない場合は Private Subnet の EC2 にセッションマネージャーで接続できない - ablog 参照。 com.amazonaws.region.ssm com.amazonaws.region.ec2messages com.amazonaws.r

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,

Linuxでddで1GBのファイルを作成し perf でプロファイリングし、Flame Graph (炎のグラフ？)にして可視化したものです。 Flame Graphs は perf(Linux)、SystemTap(Linux)、DTrace(Solaris、Oracle Linux(UEK)、Mac OS X、FreeBSD)、XPerf.exe(Windows) などでのプロファイリング結果を可視化して最も使われているコードパスを早く正確に特定することができます。実体はプロファイリング結果をグラフ(SVG)に変換する Perl スクリプトです。 下から上に行くほどコールスタックが深く、左から関数名のアルファベット順でソートされています。一番上で横幅が広い関数がCPUを長く使っています。今回は "_aesni_enc1" つまり暗号化がボトルネックになっていることがわかります。 システ

debugfs をマウントする。 [root@yazekats-linux ~]# mount -t debugfs debugfs /sys/kernel/debug blktrace でトレースを取得する。 [root@yazekats-linux work]# blktrace -w 30 -d /dev/sda -o sda === sda === CPU 0: 160503 events, 7524 KiB data CPU 1: 2788 events, 131 KiB data CPU 2: 31 events, 2 KiB data CPU 3: 114 events, 6 KiB data Total: 163436 events (dropped 0), 7662 KiB data blktrace でトレースを取得している間に fio で負荷をかける。 [yazeka

Netflix FlameScope: a new open source performance analysis tool https://t.co/ALhVppkzfd #flamescope pic.twitter.com/YrJMuJvb7p— Brendan Gregg (@brendangregg) 2018年4月4日 Brendan Gregg らの所属する Netflix の cloud performance engineering team が FlameScope というパフォーマンス可視化ツールをオープンソースで公開した。詳しくは Netflix Tech Blog 参照。 flame graphs は瞬間的なスパイクを分析しづらかったが、FlameScope により1秒未満のヒートマップでイベント発生回数の多い時間帯が可視化されピンポイントで特定期間の flam

Linux でシステムワイドに実行回数が多いシステムコールや実行時間が長いシステムコールを調べたい場合は、sysdig が便利です。 Sysdig Open Source - Getting Started With Csysdig - YouTube インストール root で以下を実行する。 rpm --import https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public curl -s -o /etc/yum.repos.d/draios.repo https://s3.amazonaws.com/download.draios.com/stable/rpm/draios.repo rpm -i https://mirror.us.leaseweb.net/epel/6/i386/epel-release-

⁠25.3.1. WWID World Wide Identifier (WWID) を使用するとデバイスを正確に識別することが可能です。 WWID 識別子は、 SCSI 標準で全 SCSI デバイスに必要とされるような永続的でシステムに依存しない ID となります。 すべてのストレージデバイスに対して必ず固有となり、 デバイスのアクセスに使用するパスに依存しません。 この識別子は、 Device Identification Vital Product Data (ページ 0x83) または Unit Serial Number (ページ 0x80) を取得するための SCSI Inquiry を発行することで取得することができます。 WWID から現在の /dev/sd 名へのマッピングは /dev/disk/by-id/ ディレクトリー内で管理されているシムリンクで確認できます。 例

ls のソースを読んでプログラマになりました - ablog というエントリを書いたが、「ls -f で返ってくるリストは何の順なんだろう？」と思った。ls -f を実行するとライブラリ関数 readdir(3) が呼ばれ、さらに getdents() システムコールが呼ばれ、dirent 構造体が返される。dirent 構造体は連結リストになっていて、次の dirent 構造体へのポインタを辿って行くことになると思われる。ディレクトリにエントリが追加されるたびにディレクトリエントリ（dirent 構造体）が繋がっていくので、たぶんエントリが追加されるときのロジックで決まるんだろうなと想像していた。DBエンジニアには自然な発想だと思う。 Linux や UNIX 関連の書籍はそこそこ揃っていると思っていたが、自宅にある本には書かれていなかった。本屋でふと、この本なら書いてるかもと思って、

NFS で iostat の await と svctm のような情報を取れるツールが欲しいと思っていたら nfsiostat という素敵なツールを見つけた。await にあたるのが avg exe (ms)、svctm にあたるのが avg RTT (ms) だと思う。 iostat の await と svctm の意味は Linux の iostat の出力結果を銀行のATMに例えて説明してみる - ablog 参照。 書式 $ nfsstat <interval> 実行例 ops/s: 秒間の read または write リクエストの発行回数 kB/s: 1秒間に read または write されたサイズ（KB） kB/op: 1回の read または write の秒間の平均サイズ（KB） avg RTT (ms): カーネルが RPC リクエストを発行してから応答までの時間

strace を使う場合、プロセスが起動している間に lsof や /proc/[pid]/fd でファイルディスクリプタ（FD）番号とファイルパスの対応を確認しておかないと、read(17, ... などと出力されている場合に、17 のファイルパスがわからなくなりますが*1、 strace 4.7 (2012年5月リリース) から -y でFD番号と対応するファイルパス Noteworthy changes in release 4.7 ================================= ... * Improvements * Added x32 personality support (x86_64 architecture). * Added -y and -P options to print file descriptor paths and filter by

Linux で strace を使ってシステムコールのトレースを調べる時によく使うオプションをメモ。 特にお気に入りのオプションは -T、-c、-ff & -o です。 書式 システムコールを詳細に追う tt: 行頭にタイムスタンプを出力(マイクロ秒) T: 行末にシステムコール内での所要時間を出力(マイクロ秒) ff: 子プロセスのシステムコールもトレースし、-o との併用でプロセス（スレッド）毎に別ファイルに出力 o: 指定したファイル名に出力。-ff と併用すると、ファイル名. に出力 s: 出力文字数を指定。デフォルト32文字。read/write システムコールなどで読み書きした内容を全て確認したい場合は、大きくする。 p: プロセスIDを指定。 $ strace -Ttt -ff -s 1500000 -o <ログ出力先ファイル名> -p <PID> もしくは $ strace

ちょくちょく、/proc/meminfo の Active が使用中、Inactive は使用可能な領域ですよねと聞かれることがあり、違いますよと話すことがあるので、出典をメモっておく。 がちゃぴん先生のブログ Activeはページキャッシュや無名ページ（注3）のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところの MemFreeとInactiveを足すことで確実に利用可能なメモリ量を算出することができます。 （実際に利用可能なメモリ量）≒（MemFree＋Inactive） この値を利用し、一定量を下回らないようにするのが、簡単・確実な

もわっとしたイメージ重視のテキトーメモ。正確性、網羅性は重視していない。 チューニングの三原則 仕事量（計算量）を減らす 仕事量は CPUコスト + I/Oコスト とも言える 行単位でデータが必要な場合は行指向、列方向でデータが必要な場合は列指向など 圧縮でI/Oコストを減らす 並列化する アムダールの法則を考慮した上で、効果が望める場合は並列化する SIMD(SQLではなくハードウェアレイヤーでの並列化) 仕事を速くする 処理自体を速くする ディスク→SSD→メモリ→L1-3キャッシュ→レジスタ Software on Silicon とか 式で表すとこうなります。 仕事量（計算量）を減らすのが一番大切 データ（オブジェクト）構造が最も大切 表、索引、パーティショニングなど - SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus) P.292 「賢い

Oracle Linux 7.1 でNFSの設定をしたのでメモ。 環境 NFSサーバ: Oracle Linux 7.1 NFSクライアント: Oracle Linux 5.3 構成 NFS Server:/home/oracle/nfs/local -> NFS Server:/home/oracle/nfs/remote -> NFS Client:/home/oracle/nfs/remote 設定手順 NFS Server ターゲット側にディレクトリ作成 $ mkdir -p /home/oracle/nfs/{local,remote} /etc/exports に以下を追記 /home/oracle/nfs/local *.oracle.com(rw,no_root_squash) NFS関連サービスを起動する # systemctl start rpcbind # syste

100MB 分のデータ領域(バッファ)を確保して、sleep するプログラムです。なお、バッファの領域を確保しただけだと bss に割り当てられてしまい実メモリを消費しないので、起動直後にそこに 100MB 分データの書き込みを行っています。 Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる - naoyaのはてなダイアリー の BSS って何の略か気になって調べてみたら、 Program Size Compilers translate a program's executable statements into CPU instructions, and declarations of static data are translated into machine-specific data specifications. To create

Shibuya.pm#12 に行って来た。本物の宮川さんを見れた！（ミーハー）。難しくてわからないところがたくさんあったけど、刺激になった。また行きたい。 最近DB(Oracle)のお勉強しているので、「 NoSQL vs. NoKVS ライトニングディスカッション」が面白かった。特定の目的に特化したデータベースを自分で作られていて、すごいと思った。 以下、とても断片的で不正確なメモ。 特別講演 宮川達彦(id:miyagawa)さん - "Tatsumaki" I/O bound HTTP clients in web frameworks Tatsumaki at Shibuya.pm Tech Talks #12 - bulknews.typepad.com まず、PSGI/Plack がわかってない。 Perl web applications と web servers のインタ

NFSの排他制御についてメモ(Linux限定) Managing NFS and NIS: Help for Unix System Administrators 作者: Mike Eisler,Ricardo Labiaga,Hal Stern出版社/メーカー: O'Reilly Media発売日: 2001/08/15メディア: ペーパーバックこの商品を含むブログを見る 11.2 NFS and file locking Mandatory locking and NFS NLM supports only advisory whole file and byte range locking, and until NFS Version 4 is deployed, this means that the NFS environment cannot support mandatory

NFSのマウントオプションで soft と hard がある。プロセスがI/Oシステムコールを発行してユーザーモードからカーネルモードにコンテキストスイッチした後、応答がないと、soft の場合はリトライを繰返した後にI/Oエラーになるが、hard の場合は応答があるまで待ち続ける。 hard + intr: kill できる*1。おそらく TASK_INTERRUPTIBLE でスリープするため。 hard + nointr: kill できない。おそらく TASK_UNINTERRUPTIBLE でスリープするため。 Kernel 2.6.25 以降、TASK_KILLABLE が導入され、NFS Client のコードでI/Oシステムコール発行後、TASK_KILLABLE でスリープするよう変更が入り、マウントオプションに hard を指定しても kill できるようになっている。

Oracle JDBC Thin Diver の oracle.jdbc.ReadTimeout について調べたことをメモ。 Oracle ACE の id:yamadamn さんのスライドがわかりやすいです。 Oracle JDBCドライバプロパティの活用 from Oracle Fusion Middleware P.11 P.12 まとめ Oracle JDBC Thin Diver の oracle.jdbc.ReadTimeout（ミリ秒） はソケット読込時のタイムアウト スレッドがソケット読込み待ちになった時点からの経過時間でタイムアウトする。 ReadTimeout > SetQueryTimeout にする理由 SELECT で少しずつ結果セットを受信するようなケースでは問題ないが、実行時間の長い SELECT で最後まで結果セットが帰って来ないケースや UPDATE や

Reducing Memory Access Latency by Satoru Moriya (Hitachi LTC) が素晴らしすぎるのでメモ。 まとめ vm.swappiness = 0 により、解放可能なページキャッシュがあるうちはプロセスのメモリ(anon page)をスワップアウトしないようにできる*1。 swappines=0 にしても 解放可能なページキャッシュがあるのにプロセスのメモリがスワップアウトされる問題があったが、この資料を書いた守屋さんのパッチが Kernel 3.5 にマージされている → mm: avoid swapping out with swappiness==0 extra_free_kbytes で kswapd がページ回収を開始する閾値を上げ、direct reclaim が発生しにくくできる Kernel 3.2 以降、direct rec