仮想スレッド/ネイティブイメージ/CRaC/ノンブロッキングにも対応! msで起動しオンプレからサーバレスまで幅広く利用できる 軽量OSSフレームワークQuarkus
![Getting Started Performance Troubleshoot](https://cdn-ak-scissors.b.st-hatena.com/image/square/01202989963d88a10d30bcfbea0028f85b4a7e90/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fad88cb16213d4e9f9b01afbe4074659e%2Fslide_0.jpg%3F16662529)
仮想スレッド/ネイティブイメージ/CRaC/ノンブロッキングにも対応! msで起動しオンプレからサーバレスまで幅広く利用できる 軽量OSSフレームワークQuarkus
I’ve recently seen some really broad tables (hundreds of columns) in a somewhat inefficiently structured database. Our PostgreSQL support customer complained about strange runtime behavior which could not be easily explained. To help other PostgreSQL users in this same situation, I decided to reveal the secrets of a fairly common performance problem many people don’t understand: Column order and c
search infra teamのmrkm4ntrです。我々のチームではElasticsearchをKubernetes上で多数運用しています。歴史的経緯によりElasticsearchのクラスタは全てElasticsearchクラスタ専用のnode pool上で動作していました。ElasticsearchのPodは使用するリソースが大きいため、このnode poolのbin packingが難しくコストを最適化できないという問題がありました。そこで全てのElasticsearchクラスタを専用のnode poolから他のワークロードと共存可能なnode poolへ移行しました。ほとんどのクラスタが問題なく移行できたのですが、唯一移行後にlatencyのスパイクが多発してしまうものがありました。 この記事では、その原因を調査する方法と発見した解消方法について説明します。 発生した現象 共
Best practices for performance tuning AWS Glue for Apache Spark jobs Roman Myers, Takashi Onikura, and Noritaka Sekiyama, Amazon Web Services (AWS) December 2023 (document history) AWS Glue provides different options for tuning performance. This guide defines key topics for tuning AWS Glue for Apache Spark. It then provides a baseline strategy for you to follow when tuning these AWS Glue for Apach
本連載では、Javaプログラムの実行を担うJava仮想マシン(JVM)について、その情報を取得するさまざまなツールの利用を通じて理解を深めます。JVMやそのツールに関する知識はアプリケーションが正常に動作しているときではなく、障害など異常が起こった際に大いに活躍します。それだけでなく、Javaプログラムを動作させる仕組みを知ることはソフトウェアを開発するエンジニアの皆さんの知的な部分を刺激するとともに、シニアレベルのJavaエンジニアへと進む第一歩となります。連載第1回はJVMの概要を解説し、模擬的なトラブルシュート体験としてヒープダンプを取得して解析します。 はじめに 今後もアプリケーションをJavaで開発、運用していくことを前提にすると、そうした業務に携わる方は次のようなことを学び続けるでしょう。 Javaの半年ごとのバージョンアップに追随して新機能などを学ぶ アーキテクチャなどでの新
今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ~はじめに~ パフォーマンスチューニング9つの技 ~「書き」について~(本記事) パフォーマンスチューニング9つの技 ~「探し」について~ パフォーマンスチューニング9つの技 ~「基盤」について~ 1. パフォーマンスチューニングの「書き」とは 一般的にデータベースは、大量データを扱い、大量の問い合わせや更新を高速に処理し、さらに障害発生
概要 データベースの性能検証によく利用されるTPC-HとTPC-DSをざっくり整理する。 TPCとは TPCとは、Transaction Processing Performance Councilの略であり、トランザクション処理性能評議会である。データベースのトランザクション性能検証を作成・検証を目的とした団体である。複数の性能検証ベンチマークがあり、TPC-E、TPC-H等が有名である。 TPCのテスト一覧 TPCのActive Benchmarksには下記のものがあり、TPC-HとTPC-DSはそのうちの1つのベンチマークである。 Benchmark/Document Current Version Specification Source Code
Try the Erasure Code Calculator to configure your usable capacity Try Now The recent announcement from AWS about the general availability of their new ARM-powered Graviton2 servers caused us to take another look at the performance of these ARM servers. In this blog post we describe the results which you may find surprising. Introduction MinIO is an Apache licensed, open source S3-compatible object
0x00. はじめに 筆者はJava製のWAF(Web Application Firewall)、Guardian@JUMPERZ.NETの開発とメンテナンスを行っている。元は自社のシステムを守るために(そして半分趣味で)作ったものだが、数年前にこれをコアのエンジンとしてさらに拡張し、SaaS型の商用サービス「Scutum(スキュータム)」を立ち上げた。 その後順調に顧客を獲得することができ、システムリソース的にも増強が必要となる段階などを経験した。Google、mixiやはてな等、さまざまな大規模サイトのインフラエンジニアの方々がインフラ設計に関する考え方などをインターネット上で公開してくれているおかげで、初期のシステム設計時に「将来的にスケールアウト可能なシステム構成にしておくこと」が重要であるということがわかっていた。その教えに従っていたおかげで、リソースの逼迫(ちなみに今回はCP
Oracle データベースの内部構造に着目して、さらなるチューニングを行うために必要な基礎知識をまとめた資料です。
balancer_by_lua_xxxxx いつの間にやら1 lua-nginx-module に balancer_by_lua_xxx という新しいディレクティブが増えていました。 以下ドキュメントより抜粋。 http { upstream backend { server 0.0.0.1; # just an invalid address as a place holder balancer_by_lua_block { local balancer = require "ngx.balancer" local host = "127.0.0.2" local port = 8080 local ok, err = balancer.set_current_peer(host, port) if not ok then ngx.log(ngx.ERR, "failed to set
lua-nginx-module で利用できるStorage(memcache, MySQL, redis)向けのアダプタを試すnginxLuaJIT せっかくだしnginx+lua-nginx-moduleのStorage向けアダプタ使いたい nginx (+ lua-nginx-module) で利用できるStorage向けのアダプタについては lua-nginx-moduleのREADME.mdに書かれている。 そのうち、リポジトリからgit cloneして、nginx.confにlua_package_pathを書いて ライブラリまでのパスさえ指定してあげれば使えるものは以下の通り。 lua-resty-memcached lua-resty-redis lua-resty-mysql Memcached, Redis, MySQL向け。Postgres向けのはlua-restyで
Site Reliability Engineering(SRE) Teamの@cubicdaiyaです。 今回は数あるnginxのサードパーティモジュールの中でも一際強力で、メルカリでも活用しているngx_luaの便利な活用方法や最適化集について紹介します。 ngx_luaは軽量スクリプト言語のLuaでnginxを拡張できるモジュールです。 nginxの設定ファイル内にLuaのコードを埋め込んだり、nginxの拡張モジュールをCではなくLuaで開発することができます。以下はngx_luaにおける「Hello, World!」です。 location / { content_by_lua 'ngx.say("Hello, World!")'; } 上記のロケーションにHTTPでアクセスするとnginxはボディが「Hello, World!」のレスポンスを返します。 なお、先月末にリリースさ
osquery is an operating system instrumentation framework for Windows, OS X (macOS), and Linux. The tools make low-level operating system analytics and monitoring both performant and intuitive. osquery exposes an operating system as a high-performance relational database. This allows you to write SQL queries to explore operating system data. With osquery, SQL tables represent abstract concepts such
Recent posts: 26 Sep 2021 » The Speed of Time 06 Sep 2021 » ZFS Is Mysteriously Eating My CPU 30 Aug 2021 » Analyzing a High Rate of Paging 27 Aug 2021 » Slack's Secret STDERR Messages 05 Jul 2021 » USENIX LISA2021 Computing Performance: On the Horizon 03 Jul 2021 » How To Add eBPF Observability To Your Product 15 Jun 2021 » USENIX LISA2021 BPF Internals (eBPF) 04 Jun 2021 » An Unbelievable Demo 2
Recent posts: 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » TensorFlow Library Performance 19 Mar 2022 » Why Don't You Use ... 26 Sep 2021 » The Speed of Time 06 Sep 2021 »
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" つまり暗号化がボトルネックになっていることがわかります。 システ
Brendan Gregg (NETFLIX の Senior Performance Architect) 作の Java Mixed-Mode Flame Graphs を使うと Java のプロセスが CPU ネックのケースで、Java アプリケーションコード、JVM(HotSpot VM)、Linux Kernel のどのレイヤーのどの関数がボトルネックになっているかを簡単に特定することができます。 以下は GitHub - martint/jittest: Demonstrate JIT compiler issue in java 7 のワークロードを実行して Flame Graphs で可視化したものです。 以下は Java One 2015 での Brendan Gregg のスライドです(YouTube もあります)。 JavaOne 2015 Java Mixed-Mo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く