OSC・シェルのプロが語る『make を使ったデータ処理。』 【make 教】 - OSC2015 Tokyo/Spring 発表資料
OSC・シェルのプロが語る『make を使ったデータ処理。』 【make 教】 - OSC2015 Tokyo/Spring 発表資料
Hi, I’m Mark Nottingham. I write about the Web, protocol design, HTTP, Internet governance, and more. This is a personal blog, it does not represent anyone else. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social other HTTP APIs posts Designing Headers for HTTP Compression Tuesday, 27 November 2018 How to Think About HTTP Status Codes Thursday, 11 May 2017 Five Reasons to Con
The term CPU, which stands for central processing unit, is a misnomer for most systems, since central implies single, whereas most modern systems have more than one processing unit, or core. Physically, CPUs are contained in a package attached to a motherboard in a socket. Each socket on the motherboard has various connections: to other CPU sockets, memory controllers, interrupt controllers, and o
割り込みについて調べてみたのでメモしておきます。 ほとんどは 詳解 Linuxカーネル 第3版 で調べた内容なので、x86 と Linux よりの内容になっていると思います。 「割り込み」ってなんだろ？（2012/03/04追記） 「割り込み」は何らかの要因によって今やっている仕事をやめ、急遽別の仕事をすること。 仕事中に電話がかかってきて、仕事を中断して電話に出るのは割り込みの概念と同じ。 コンピュータにおいても人間がキーボードをいつ押すかコンピュータにはわからないが、コンピュータがずっとキーボードを監視していたのではほかの処理ができない。何か処理を実行中でもキーボードが押されると割り込んで、キーボードから入力されたデータを受け取って必要な処理を行ってから元の処理を再開する。 このように何かイベントが起こったときにCPUにそのことを知らせ、そのイベントにあった処理をして、その処理が終わる
Linux ではカーネルモードでCPUが使われるのは、システムコール、割込み、カーネルスレッドの3つだと思うが、割込みは %sys にカウントされない。ハードウェア割込みは %irq、ソフトウェア割込みは %soft にカウントされる。 %irq Show the percentage of time spent by the CPU or CPUs to service hardware interrupts. %soft Show the percentage of time spent by the CPU or CPUs to service software interrupts. mpstat(1): Report processors related statistics - Linux man page
つれづれなるままに、日ぐらしパソコンに向かひて、心にうつりゆくデータベースの性能問題の切り分け方法をそこはかとなく書き付くれば、あやしうこそ物狂ほしけれ。なエントリ（書きかけ）。一度、脳内をフラッシュしてからまとめるべし。 性能問題による影響 性能問題による影響を以下の2つに分類する。 システム全体が遅い 一部の処理が遅い 性能問題の原因 性能問題の原因を以下の2つに分類する。 交通量が多い 単純に交通量が多くて渋滞している 例）年末年始やお盆の帰省ラッシュやUターンラッシュ 経路の途中で詰まっている 車線減少や通行止めなどで渋滞している 例）年度末の工事による車線減少、飲酒の検問、交通事故による通行止めなどで経路のどこかで詰まっている 切り分け手順の分類 システム全体が遅いケースと一部の処理が遅いケースで切り分け手順は変わる。 切り分けはOSレイヤーとデータベースレイヤーの2つの観点から
最近、マクドナルドのレジカウンターの店員がサーバー・プロセス、その後ろでハンバーガーやポテト、ドリンクなどを作っている店員がバックグラウンド・プロセス、並んでいる客がクライアント・プロセスに見える今日この頃です。 vmstat でCPU負荷を見るときになぜ使用率だけじゃなくて"r"列を見る必要があるかについて、マクドナルドの店頭で例えてみるとわかりやすいのではないかと思って絵を描いてみました。以下はいずれも店員のガンバリ具合（CPU使用率）は 100% で、行列（"r"列）の数だけ異なる絵です。店員は客の数に関わらず 100% でオーダーを処理します。これは客が1人でも、10人の行列ができていても同じです。 1. CPU使用率100%でvmstatの"r"列が「4」の場合 2. CPU使用率100%でvmstatの"r"列が「8」の場合 3. CPU使用率100%でvmstatの"r"列が
vmstat の"r"列とマクドナルドのレジカウンター - ablog の iostat 版です。 以前、iostat の見方 - ablog というエントリを書きましたが、 絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection) 作者: 小田圭二出版社/メーカー: 翔泳社発売日: 2008/04/22メディア: 単行本（ソフトカバー）購入: 22人 クリック: 303回この商品を含むブログ (36件) を見るP.176 LIST 1 Linuxのiostat -x 30の出力結果を分析 を元に説明してみます。 $ iostat -x 30 avg-cpu: %user %nice %sys %iowait %idle 15.46 0.23 3.70 45.05 35.55 Device: rrqm/s wrqm/s r/
Over time, Red Hat Enterprise Linux's network stack has been upgraded with numerous automated optimization features. For most workloads, the auto-configured network settings provide optimized performance. In most cases, networking performance problems are actually caused by a malfunction in hardware or faulty infrastructure. Such causes are beyond the scope of this document; the performance issues
id:studio-m (nekoyaさん)にblogエントリで先を越されたけど自分はちょっと使い所と事情が異なっていそうだったのでそれを書いておきたく!! 0. RPS/RFS の利用 CentOS5 系でのやり方は nekoyaさんのエントリ を見てください。 CentOS6 系でのやり方は kazeburoさんのエントリ を見てください。 自分はkernel 2.6.39で試しましたが問題なく動作しました。 1. RPS/RFSの利用を迫られた背景 nekoya さんは app サーバの所でネットワーク問題が起こっていたようですが、自分の場合 LVS と outbound のトラフィックをさばいているLinuxルータで厳しいことになってきておりました。 この時発生する具体的な症状として LoadAverage が 1 で張り付いて応答が極端に悪くなる というものがあります。 これをど
Java HotSpot™ Virtual Machine Performance Enhancements Tiered Compilation Compressed Oops Zero-Based Compressed Oops Escape Analysis NUMA Collector Enhancements Tiered Compilation Tiered compilation, introduced in Java SE 7, brings client startup speeds to the server VM. Normally, a server VM uses the interpreter to collect profiling information about methods that is fed into the compiler. In the
DBサーバでとある日を境にswapが発生していることに気がつきました。 サーバはメモリ32GB搭載していて、そのうちの24GBをinnodb_buffer_pool_sizeに割り当てています。 他のthread毎のメモリ設定値を見てもおかしそうな点はなかったのでググってみました。 MySQL と NUMA アーキテクチャと Swap Insanity MySQL InnoDBストレージエンジンのチューニング（後編） なるほど…。 それぞれのCPUがローカルでメモリを管理しているので、 2CPU積んでいるサーバだと、AというCPUで実行されているスレッドが、BというCPUが確保しているメモリ領域にアクセスするには、AのCPUを経由しないといけないわけですね。 このメモリアクセスが不均一になる方式をNUMAアーキテクチャというみたいです。 NUMAアーキテクチャのメモリ管理が、ノードという単
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く