
【Unit4 ブログリレー3日目】 こんにちは,エムスリーエンジニアリンググループの榎田です.数学とテレビゲームが好きです. 今回は,Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します.普段の私が意識していなかった, RDBMS の内部機構に関する話が登場して面白かったので,今回の記事を書きました. なお,本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており,特にその他の RDBMS で同様の動作をするかは確認していません.定性的な挙動に共通するものはあるかもしれませんが,ここで述べた話はそのままは通らないであろうことをお断りさせてください*1. プロダクトについて index なしで意外と耐えたが,耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第11代黒帯(ヤフー内のスキル任命制度/Webフロントエンド領域)の浜田(@narirow)です。今回はヤフー全社で実施してきた、「Webパフォーマンス改善プロジェクト」についてお話ししたいと思います。 長期に渡る活動の結果、多くのサービスのWebパフォーマンスが徐々に向上しています。この記事では、取り組みの経緯や、多くのサービス分析を通してわかったコスパの良い施策(比較的簡単に実施できてスコアも上がりやすい施策)などをご紹介します。 全社横断でWebパフォーマンス改善を実施する経緯 さかのぼること2021年、Googleから以下のような案内がありました。 「Core Web VitalsがGoogle検索の検索順位に
MySQL では sort_buffer_size 以上にソート領域が必要になった場合、もしくは一部の条件に当てはまるSQLについては、内部一時テーブルを作成し処理を行うという仕組みになっています。 8.4.4 MySQL での内部一時テーブルの使用 この内部一時テーブルの仕組みに MySQL 8.0 から TempTable ストレージエンジンを利用する事ができるようになりました。 TempTable ストレージエンジンの挙動については、過去の弊社ブログ記事で説明しています。 TempTable ストレージエンジンについて TempTable ストレージエンジンはMySQL 8.0で導入されたということもあり、初期パッチバージョンに比べて改善が行われています。 今回の記事では、TempTableストレージエンジンの最近追加された機能についてご紹介します。 基本的なソートバッファと内部一時
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした!障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
おはようございます、なのくろです。年の瀬ですね。 この記事は ABEJA Advent Calendar 2020 の最終日です。 追記:おかげさまで Qiita LGTM賞 を受賞いたしました、ありがとうございます! 私は2020年01月にABEJAへ入社しました。チームではフロントエンド開発全般を任されています。 参入してちょうど1年が経過しましたので、今年取り組んだことをまとめました。 「フロントエンドを100倍速く」というタイトルは誇張気味なのですが、難しいことはせず、基本的なパフォーマンス改善を素直に実践したという話を書きます。 本稿では事例とやったことを紹介するのみですが、何かしらの知見や改善のきっかけに役立てば幸いです。 サービスについて 話をする前に、どんなサービスを開発しているかについて少しだけ触れます。 ABEJA社では「Insight for Retail」という、小
はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8%から58%に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
English version 要約 dockerはデフォルトでセキュリティ機構(Spectre脆弱性の対策)を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります(実行時間が倍くらいになることがあります)。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合: $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース(
この記事は Akatsuki Advent Calendar 2019 1日目の記事です。 はじめに アカツキでは Ruby on Rails を使ったゲームサーバを開発・運用しています。ゲームの体験を向上するために、レスポンスタイムは一つの重要な要素となるため、種々のパフォーマンスチューニングを行なっています。今回はその一例として、環境変数を1つ設定するだけで、あるAPIのレスポンスタイムが10%も改善した例をご紹介します。 TL;DR 多数の時刻を含むレコードを扱う Ruby on Rails サーバでは、 TZ 環境変数を設定することで、デフォルトタイムゾーン設定ファイル /etc/localtime へのアクセスが減り、高速化が図れるかもしれません。 効果は Time オブジェクト1個あたり数μsの短縮といったオーダーですが、チリも積もれば山となり、数千個のレコードを処理するAPI
Linuxバイナリを最適化して性能を向上させる「BOLT」、Facebookがオープンソースで公開。言語やコンパイラに依存せず高速化 Facebookは、Linuxバイナリの内部配置を最適化することによりCPUのキャッシュ効率などを向上させ、実行速度を改善する「BOLT」をオープンソースで公開しました。 BOLTは「Binary optimization and layout tool」の略とされています(もしかしたら、より速く走るという意味でウサイン・ボルト氏にかけているのかもしれません)。 BOLTは言語やコンパイラに依存せず、ソースコードも不要 BOLTのおもな効果は、Linuxバイナリの実行状況をperfコマンドで取得し、高頻度で実行されている部分などを判別した上で、そうした部分がCPUキャッシュにヒットしやすいようにバイナリの内部配置を改善することなどで実行速度を向上させることと
「爆速すぎて笑う」「速すぎて逆に不安になるレベル」――「dev.to」という米国のWebサイトの表示速度が異常に速いと、ネット上で話題だ。なぜ速いのか、サイト創設者のベン・ハルパーンさんがサイト内の記事で説明している。 2016年にオープンしたdev.toは、プログラマーが情報を交換したり、議論したりできるコミュニティーサイト。トップページにはユーザーが投稿したブログ記事のタイトルやコメントが、SNSのタイムラインのように並んでいる。このトップページの表示にかかる時間、各記事をクリックしたときのページ遷移が“一瞬”なのだ。 なぜ速いのか。ハルパーンさんが17年2月に投稿したブログ記事によれば、米Fastlyが提供するCDN(Content Delivery Network)を活用している。CDNは世界中にキャッシュサーバを分散配置し、ユーザーごとに最も(ネットワーク的に)近いサーバにキャッ
可能な限り最新の情報を反映していますが、追いつけていないこともあります。本サイトに採用していても、記事に反映できていない設定もあります。ページのソースを読んでいただくと、参考になる箇所があるかもしれません。 ウェブページの高速化に関するテクニックは、ネットで検索すれば簡単に見つけることができます。優れた情報も数多くありますが、「CSSとJavaScriptはminify(ミニファイ)しておけばOK!」のような都市伝説も少なくありません。 そこで、ここでは本サイトのデザインリニューアル時に施した対策をもとに、一歩進んだウェブページの高速化の方法と、それを支える原理について、できる限り分かりやすく説明したいと思います。フロントエンジニアやデザイナーの方からすれば「んなもん知っとるわ!」な情報なのかもしれませんが、都市伝説を駆逐すべく、私なりの仕方で解説(≒加勢)したいと思います。 初めに結果を
PostgreSQL Advent Calendar 2014 の 13日目です。 Advent Calendar を今年もやってみたいと思って、枠が空いていたので飛び込んでみました。 昨日は osapon さんの libpqxx を使ってみたでした。 概要 PostgreSQL のパフォーマンスチューニングは大きく下記に分かれます。 システムチューニング SQL チューニング ここでは Linux 上で動かしていることを前提に、それぞれ説明します。 システムチューニング システムチューニングの概要 システムチューニングとは、OS または PostgreSQL の設定を変更することです。 それぞれ順に説明します。 OS チューニング PostgreSQL では特にメモリ関連でOSパラメータを設定変更すると、高速化効果が得られます。 特に下記のカーネルパラメータに注意します。 vm.dirt
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
エルミタ的「編集部で使ってみた」 NVMe SSD発熱問題の解決策。コスト1,000円以下でパフォーマンスは向上できる 2016.11.05 更新 文:GDM編集部 池西 樹 本格的な普及期へと移行したNVMe SSD。エルミタでもPLEXTORやIntelなど主要モデルの検証を行い、圧倒的なパフォーマンスを知る事になる。一方で発熱の高さによるパフォーマンスの低下という課題が見えてきた。安定した性能を発揮するには冷却対策が重要になる。そこで、今回はNVMe SSDの効果的な冷却方法を探るべく、汎用ヒートシンクによる冷却やヒートプレートの自作に挑戦する。 現状ほとんど選択肢がないNVMe SSD専用冷却アイテム 広大な帯域幅と最新プロトコルの対応により、SATA3.0(6Gbps) SSDを遥かに超える転送速度を実現したNVMe SSD。それに伴い発熱も大幅に増加。常に安定したパフォーマンス
第3回になります。 記事を書くこと自体に時間がかかってしまうので 見やすい記事にするってのが難しいですね。。 少しずつ改良していきます。 ストックやフォローをして頂けると励みになります。 さて、本題です。 jstatやGCログなどを見てメモリがなかなか開放されない場合は ヒープダンプを取ってメモリの中身を解析することになります。 ヒープダンプの取得 まず、jstatやpsコマンド等で対象のJVMのプロセスIDを取得しましょう。 これで指定した場所にダンプファイルができます。 -dump:live,format=...というようにliveをつけるとGCが起きて コマンド実行時に活きているオブジェクトのみのダンプになるようです。 とりあえず今回はフルで取ります。 ヒープダンプの中身を解析をする 解析をするにはツールを使います。 java標準のjhatやMemory Analyzer、HeapA
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く