
Percona Database Performance Blogの翻訳。Linux上でMySQLサーバを運用する際の、カーネル、ファイルシステム、メモリなどのチューニングのポイントをまとめた記事。 [MySQL][Linux]原文 Linux OS Tuning for MySQL Database Performance - Percona Database Performance Blog (English) 原文著者 Spyros Voultepsis 原文公開日 2018-07-03 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー taka-h 原著者への翻訳報告 2414日前 原文へのコメントで報告済み 編集 この記事では、MySQLデータベースサーバーのパフォーマンスチューニングと最適化のために調整する重要なLinuxの設定を復習します。OSのチューニングに使う
I've seen power-Visual Studio users do amazing things with the profiler and debugger. It looks amazing, but there is one small problem. I'm on Linux. No visual studio for me. How do I profile now? There are some profilers out there for Linux too, each with varying degrees of usability. Perf is a neat little tool that I just found for profiling programs. Perf uses statistical profiling, where it po
1. 概要 SQLiteを使うと小さなBLOB(例:サムネイル画像など)を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35%も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20%も節約可能です。 このようなパフォーマンスの差が生じる理由は、(私たちの考えでは)SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
How is GNU's yes so fast? $ yes | pv > /dev/null ... [10.2GiB/s] ... Compared to other Unices, GNU is outrageously fast. NetBSD's is 139MiB/s, FreeBSD, OpenBSD, DragonFlyBSD have very similar code as NetBSD and are probably identical, illumos's is 141MiB/s without an argument, 100MiB/s with. OS X just uses an old NetBSD version similar to OpenBSD's, MINIX uses NetBSD's, BusyBox's is 107MiB/s, Ultr
興味があって調べていたら、少しだけ分かったのでまとめておきます。当然間違った箇所もある、あと考慮が漏れている箇所もあるかと思いますのでツッコミをお願いします… ptrace(2) システムコール strace の核となるシステムコールは ptrace(2) である。ptrace(2)を用いることで、あるプロセスを別のプロセスから監視し、シグナルごとに停止してレジスタやメモリの状態を観察したり変更したりできる。gdbのようなデバッガのブレークポイント、あるいはまさにstraceのような目的で利用される。 大まかな利用方法としては、親プロセスの ptrace(PTRACE_ATTACH, pid, ...) (または子プロセスの ptrace(PTRACE_TRACEME, 0...))によりトレースが開始し、wait()などで停止を待ってから様々な設定を親から送り、 ptrace(PTRAC
はじめに Linux で採取できるCPU使用量(率)の情報として、%user や %sys 等に加えて %steal という量がある。これが追加されたのは、仮想化が広く使われはじめた10年くらい前だろうか。筆者は Xen を調べていて気づいたのだが、もっと前にs390のために追加されたのかもしれない。当時、ESXの場合も含めて調べていたのだが、最近、KVMの場合にどういう実装になっているのか、ふと気になって軽く調べてみたのでメモ。 CPU使用率の計算 まず最初に、sar や vmstat や mpstat 等、さまざまなツールでCPU使用率を取得することができるわけだが、どのような情報を元に、どのような計算を行って算出しているのか? まず、kernel内ではboot以後の各種実行モードのCPU時間を分類して積算値として保持している。user モード、特権モード、割り込み処理に使った時間..
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? (2019/6/12追記) 今なおこの記事を参照してくれる方がいらっしゃるのですが、現在は以下のスライドのほうが情報が新しいです。 本記事は残しておきますが、新しい情報はこちらをご参照ください。 https://www.slideshare.net/ygotokernel/nvdimmlinux-137104084 はじめに Linux Advent Calendarの24日目の記事として不揮発メモリの状況について記載したいと思います。今回はkernelのソースの中とかのあまり技術的に深いところは突っ込まず、概略レベルです。(深いところ
CPU、もしくはストレージがボトルネックになっている場合、vmstatコマンドを用いて切り分けを行います。 [root@test ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 271328 110320 59792 392132 0 0 1 165 0 5 1 0 88 11 0 0 0 271328 110304 59792 392132 0 0 0 16 101 175 1 0 99 0 0 0 0 271328 110304 59792 392132 0 0 0 436 154 276 0 0 98 2 0 右から3番目の
First, your dtrace script will give you an upper bound on the maximum memory utilization since you don't track frees as well as mallocs. You might not care about this. If you do care, since free doesn't take in or return the size of the freed range, you might be better off tracing the brk() syscall return value, which also accounts for the size of all metadata that malloc stores on the heap. The a
自分が書いたプログラムのメモリ使用量を測定したいことがある。プログラムがOOM Killerによってお亡くなりになった場合や、ページフォルトをなくして高速化したい場合などだ。定常的に起動するサーバーのプログラムなら、sarや meminfo など(今なら Datadog とかだろうか)を使ってじーっと見つめるわけだ。もっとモダンにやるなら perf や DTrace を使ってもよいかもしれない。しかしこれらのツールは基本的にプロセスIDを渡してサンプリングして外から覗く方法だ。 わたしのユースケースはデーモンプロセスではなく、 main から入って必要な計算をして、それが終わったら main を抜けるバッチジョブ(単にコンソールから実行して終わるまで待つ、いわゆる "Hello world!" 的なやつ)だ。これだと、プログラムが起動して終わるまでそこそこの時間で終わってしまって、外部プロ
Talk for PerconaLive 2016 by Brendan Gregg. Video: https://www.youtube.com/watch?v=CbmEDXq7es0 . "Systems performance provides a different perspective for analysis and tuning, and can help you find performance wins for your databases, applications, and the kernel. However, most of us are not performance or kernel engineers, and have limited time to study this topic. This talk summarizes six import
Linux 4.7 CPUFreq Schedutil Testing vs. P-State Written by Michael Larabel in Software on 21 May 2016 at 12:11 PM EDT. Page 1 of 5. 19 Comments. With the in-development Linux 4.7 kernel there is a new CPUFreq governor that leverages the kernel's scheduler utilization data in an attempt to make better decisions about adjusting the CPU's frequency / performance state. Here are some benchmarks of tha
システムの電力消費と熱出力を削減する最も効果的な方法の 1 つは、CPUfreq です。CPUfreq は CPU 速度スケーリングとも呼ばれ、Linux カーネルのインフラストラクチャーで、電力を節約するために CPU 周波数をスケーリングできます。CPU スケーリングは、システム負荷に応じて、ACPI イベントに応答して自動的に、またはユーザー空間プログラムによって手動で行うことができ、プロセッサーのクロック速度をその場で調整できます。これにより、システムは減速したクロック速度で実行でき、電力を節約できます。周波数のシフトに関するルール (クロック速度の高速化または低速化、および周波数のシフト) は、CPUfreq ガバナーで定義されています。
Video: https://www.facebook.com/atscaleevents/videos/1693888610884236/ . Talk by Brendan Gregg from Facebook's Performance @Scale: "Linux performance analysis has been the domain of ancient tools and metrics, but that's now changing in the Linux 4.x series. A new tracer is available in the mainline kernel, built from dynamic tracing (kprobes, uprobes) and enhanced BPF (Berkeley Packet Filter), aka
前回(LinuxのBPFとbccでデバッグする - φ(・・*)ゞ ウーン カーネルとか弄ったりのメモ)はbccを使ってkprobeでカーネル内の関数にprobeを設定したので今回はユーザーランドのほうでuprobesを使うメモ。 fork()が呼ばれたときにプロセス名、pid等を表示する。 #!/usr/bin/env python from bcc import BPF bpf_source = """ #include <uapi/linux/ptrace.h> void fork_enter(struct pt_regs *ctx) { bpf_trace_printk("fork()\\n"); } """ b = BPF(text=bpf_source) b.attach_uprobe(name="c", sym="fork", fn_name="fork_enter") wh
最近公開されたスライドでLinuxのパフォーマンスチューニングとかDTraceで有名なBrendan GreggさんのLinux BPF Superpowersが面白かったのでBPFとbccに手を出してみました。 BPFはLinuxカーネルのパケットフィルタリングの機能で、その名の通りBerkeley Packet Filterです。bcc「BPF Compiler Collection」というのはBPFを使いやすくするためのツールです。 BPFを使う場合、一番基本的なのはbpf(2)を使ってc言語で書くことだと思います。bccはpython+c言語でBPFを使うようになっています。 (´-`).oO(BPFとbccの関係というのはkprobesとsystemtapの関係に近いような気がします で、Berkeley Packet Filterでデバッグってなんだよ?ってなると思うのですが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く