データサイエンティストの皆さん、次のような性能問題にであったことないでしょうか。「データの加工処理が遅いからインスタンスタイプを上げたが速くならなかった」「機械学習の学習が遅いから、GPUを増やしたが、速くならなかった」こういったときにどうすればよいか説明します。
BPF Performance Toolsを読んだので、感想ブログです。 先に感想を言っておくと「最高」でした。 BPF Performance Toolsとは? NetflixでKernel・パフォーマンスにかかわるチューニング・アーキテクチャを専門にしているBrendan Greggさんが書いた本です。BPFのiovisorというTracing分野の第一人者でもあります。 www.brendangregg.com 2019年12月に発売したばかりなので、BPFの分野では最新の本でしょう。他の著書に有名な本として(日本語版の)「詳解システム・パフォーマンス」があります。 BPF Performance Toolsは「詳解システム・パフォーマンス」第二弾と言えるかもしれません。ちなみにページ数は880Pあり、Kindleで表示される読み終わるための平均的な時間は「27時間30分」で、大作R
September 29, 2025 by Hayden James, in Blog Linux This list of Linux benchmark scripts and tools should prove helpful for quick performance checks of CPU, storage, memory, and network on Linux servers and VPS. Check each script before running it from the command line. Most of these scripts will benchmark the CPU, memory, storage, and network. In most cases, the CPU model, frequency, and number of
Linuxバイナリを最適化して性能を向上させる「BOLT」、Facebookがオープンソースで公開。言語やコンパイラに依存せず高速化 Facebookは、Linuxバイナリの内部配置を最適化することによりCPUのキャッシュ効率などを向上させ、実行速度を改善する「BOLT」をオープンソースで公開しました。 BOLTは「Binary optimization and layout tool」の略とされています(もしかしたら、より速く走るという意味でウサイン・ボルト氏にかけているのかもしれません)。 BOLTは言語やコンパイラに依存せず、ソースコードも不要 BOLTのおもな効果は、Linuxバイナリの実行状況をperfコマンドで取得し、高頻度で実行されている部分などを判別した上で、そうした部分がCPUキャッシュにヒットしやすいようにバイナリの内部配置を改善することなどで実行速度を向上させることと
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
Linuxサーバの「OSリソースのパフォーマンス分析方法」の3回目です。性能問題が発生して処理遅延やスループット低下が見られた場合や、将来的な処理量増加に備えて設備増強を検討する場合には、OSリソースの使用状況の分析が重要です。今回は、ストレージとネットワークの使用状況について、どのような観点から分析を行っていくかを解説したいと思います。 前回説明したこと OSリソースを大まかに分けると、CPU、メモリ、ストレージ、ネットワークの4つ CPUとメモリの使用状況について、どのような観点から分析を行っていくか 前回のページへ 注意 本稿の動作確認環境は、Red Hat Enterprise Linux 6.4(以下、RHEL6.4)+sysstat9.0.4です。 sysstatパッケージがインストール済みであることが前提です。 本稿に基づく運用については、お客様自身の責任と判断によって行って
CPUやメモリ、IOといったリソースの制限下でとあるコマンドを実行させたい場合に、cgroup上に何かgroupを作ったりしてからcgexecを実行して、実行後はそのgroupを消す、といったような一手間かかる方法がほとんどでした。 実行後のgroupも綺麗にしたい、といった所まで考えるとなかなか手間がかかっていたので、それらを全てワンラインでできるrconというワンバイナリで動くツールを作りました。 github.com 例えば、負荷サーバでの調査ツールを流す際に、CPUとかIOとかを制限しつつドロドロ実行したい場合等に便利です。Linuxのcgroup対応した環境でのみ動きます。 使い方 ほぼREADME通りなのですが、オプションは代替以下のようになっています。 --memは変なので--memoryに変更しました!! ./rcon --help Usage: rcon [options
You log in to a Linux server with a performance issue: what do you check in the first minute? At Netflix we have a massive EC2 Linux cloud, and numerous performance analysis tools to monitor and investigate its performance. These include Atlas for cloud-wide monitoring, and Vector for on-demand instance analysis. While those tools help us solve most issues, we sometimes need to login to an instanc
システムコールの所要時間は strace の -T オプションで調べることができる。 上はEXCELでピボットテーブルを使ってグラフ化したもの I/Oレスポンス(read システムコールの所要時間)は5〜15ミリ秒であることがわかる 例 strace でシステムコールのトレースを取得する $ strace -ttT -o strace-T_fs_`date +'%Y%m%d%H%M%S'`.log dd if=OVMRepo.vmdk of=/dev/null iflag=direct bs=1M count=1000 -T: システムコールの所要時間(秒.マイクロ秒)を出力 ※マイクロ秒=1/1,000,000秒 -tt: タイムスタンプをマイクロ秒で出力 -o: トレースを指定したファイルに出力 出力結果 $ less strace-T_fs_20150111143101.log [.
Linuxの標準コマンドは強力なものではあるが、実際に人間が使う際にわかりやすいか、というと十分ではない。 そこで、今回はLinuxの標準コマンドから乗り換える事が可能なコマンドラインユーティリティーを調査、整理してまとめてみることにした。 1.df → dfc まずはこれ。以前にこちらでも記述している。 dfコマンドをより分かりやすくしたコマンドで、バーで利用率を認識することが出来る。 インストールは以下のコマンドで行える。 sudo apt-get install dfc (Debian or Ubuntu) 2.vmstat → dstat パフォーマンスのモニタリングでよく用いられるvmstatを、更に拡張したコマンドであるdstatにする。 dstatには、vmstatにはないネットワークに関するパフォーマンスが追加されており、見た目も見やすくなっている。 インストールは以下のコ
cpuspeed がオンだと.... — はせがワン (@hasegaw) 2014, 5月 29 ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。 経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。 パワーマネジメントに関する設定はオフにする UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。 Hyper Threading はレイテンシーとスループットのトレードオフ Hyper Threadingは、たぶん、コア内でパイプラインを取り合うから
Post navigation ← Previous Home > Web関連 > 開発 > Linux > Linuxカーネルチューニングのメモ Linuxカーネルチューニングのメモ サーバー向けにLinuxカーネルのチューニングを行った際のメモです。 設定内容 今回行った /etc/sysctl.conf の設定内容は書きの通りです。 各パラメータの説明はコメントとして残しておきます。 # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824 # システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144 # システム全体のプロセス数の上限 kernel.threads-max = 1060863 # システム全体のファイルディスクリプタの上限 fs.file-max = 5242880
Here is four strong monitoring tools i would like to present for you. htop - interactive process viewer You may know the standard tool for watching real time processes on your machine top. If not, run $ top to see it in action, and $ man top to read the manual. The htop is a widely extended version of top, with a big overview (eg. full commands, visualization, gui and ui), a mouse-clicking interac
比較的新しいカーネルを採用したLinuxディストリビューションでは、ファイルシステムのI/Oバリア (I/O barrier)機能がデフォルトで有効になっています。例えばRedhat Enterprise Linux (RHEL) 6やSUSE Linux Enterprise Server (SLES) 11等はインストール直後の状態でext4ファイルシステムのI/Oバリアが有効になっているようです。 I/Oバリアは簡単にいうと、「バリア命令」の後で発行されたI/Oは、バリア命令の前に発行されたI/Oの後に必ず実行されるようにする仕組みです。つまりI/Oの順序(物理ディスクに反映される順番)をまもらせる仕組みといえます。 ファイルシステムにI/Oバリア機能が追加されたのは、ファイルシステムが不整合な状態になる可能性を減らすためです。 そもそも、急な電源断でもファイルシステムの不整合が起こ
“爆速” 導入の舞台裏!デジタル庁が提供する「デジタル認証アプリ」の活用で実現「安全で簡単な本人確認システム」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く