第16回 StringBeginners での発表資料
第16回 StringBeginners での発表資料
MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関
1.はじめに 1-1.この記事の要旨 1-2.(予習)メモリに関する指標とlinuxのメモリ挙動について 2.検証環境と検証方法 2-1.検証環境 2-2.検証方法 2-3.測定方法 (1)psコマンドによるVSZ,RSS情報の取得 (2)freeコマンドとmeminfo情報の取得 3.結果 3-1.全体の結果 3-2.プロセスのVSZ/RSS挙動 ポイント① malloc()した時の挙動→VSZのみ増加 ポイント② 1回目のデータread時→RSSは増えない ポイント③ データwrite→RSSが増加する 3-3.システムワイドな挙動(freeコマンド/meminfo) ポイント① malloc()した時の挙動→usedもAnonymousPageも増えない ポイント②1回目のデータread時→変化しない。 ポイント③ データwrite→used上昇、AnonymousPage上昇 4.
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
fluentdな人達と話していると定期的にRubyのオブジェクト生成が遅いとdisられます。 本質的にしょうがない部分もあるんですが、それにしても遅い部分も結構あるので、おもむろにperf statとperf recordを取ってみましょう。 % sudo perf stat -d ./miniruby -e'GC.disable;i=1000000;while (i-=1)>0;Hash.new;end' Performance counter stats for './miniruby -eGC.disable;i=1000000;while (i-=1)>0;Hash.new;end': 467.629812 task-clock (msec) # 0.993 CPUs utilized 19 context-switches # 0.041 K/sec 2 cpu-migratio
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
コンパイラーを負かす
roguelazer's website: beating the compiler なかなか面白かったので翻訳して紹介する。 たとえば、97%の場合において、僅かな効率など忘れるべきである。。早すぎる最適化は諸悪の根源である。とはいえ、残りの重要な3%の機会を逃すべからず。 -- Donald Knuth 計測せよ。計測するまで速度の最適化を施してはならぬ。たとえ計測したにせよ、一部のコードが残りを圧倒するまではまだ最適化してはならぬ。 Rob Pike 最新のWebサービスを主体とした技術の業界に長年浸かった我々は、パフォーマンスの問題を忘れがちである。SQLAlchemy ORMの中で行うリクエスト一つが8,9秒かかる中で、関数呼び出しひとつを3ミリ秒最適化したところで何になるというのか。とはいえ、時にはそのような最適化スキルを養っておくのもいいことだ。今回は、ある簡単な課題を最適化
プログラミングの「常識」は時代とともに変化します。そのひとつが、サーバプログラムにおけるバッファ処理です。 1990年代後半から2010年頃までは、メモリ空間の大きさ（32bitすなわち4GB注1）を超える大きさのファイルを扱う時代でした。このため、httpdなどのサーバプログラムにおいても、入出力データをいったんテンポラリファイルとしてバッファリングする必要がありました。ですが、ファイルI/Oはメモリアクセスと比べると低速です。このため、小さなサイズのデータについてはメモリアクセスする一方で、大きなサイズのデータについてはファイルI/Oを用いる、という煩雑なコードを書く必要がありました。 しかし、2014年も暮れとなる今 、サーバサイドにおいては64bit環境のみを考えれば良い時代に入りつつあります。 もちろん、64bit環境といったところで、64bit空間の全てをユーザプロセスが使える
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
performance昨日の続き。ddコマンドによる負荷掛けだとどうしてもrun queueが出ちゃうから、I/O負荷がホントにload averageに計上されるの？というところが怪しい。それを疑うために、stressコマンドというものを使ってみました。stress project pageこいつはシステムにCPUやI/O、メモリの負荷を意図的にかけられるユーティリティ。なんて便利なものが・・！下記サイトで知りました、有り難うございます。Linuxでシステムに対して意図的に高負荷をかけたい場合 - RX-7乗りの適当な日々 早速yumでインストール。 yum install stress で、検証開始。I/O負荷をかける時は、stressコマンドに--hddオプションを付け足す。マニュアルによると、hddオプションはspawn N workers spinning on write()/
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
1. CPU使用率を上げる 1-1. (要Perl) perl -e "1 while 1" 1-2. (要Bash) while true; do true; done 1-3. (要Python) python -c "while True: True" ※CPUコアが複数の場合はその数だけ並列で実行する 2. ロードアベレージを上げる(UNIX/Linuxのみ) top -d .00001 ※上がりにくい場合はウェイトをより小さくする、もしくは複数並列で実行する 3. メモリ、スワップ使用率を上げる 3-1. (要Perl) perl -e "$c[$_]='a'x$_ for 1..1000000" 3-2. (要Python) python -c "range(1,100000000)" ※足りない場合はエンドの数を増やす ※Pythonの方はCtrl+Cで中断できない(要kil
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 といっても、きちんとした検証をしたわけではないので、あくまで「こういう環境でこういう事をやるとこうなる」という参考程度のものと理解してい頂ければ幸いです。 Linux上でプロセスは同時に何個起動できるのか 数年前にC10K問題が流行りました。これは、簡単に言うと、万のオーダーでプロセスを立ち上げる事になると、現状のOSではそれを想定した設計になっていないためまともに動かなくなる、といった問題でした。 だったら、「10万プロセス位を同時に立ち上げてみて、どうなるか試してみようぜ！」と思い、会社のエンジニアと一緒に試してみました。検証環境は、メモリ48GでCPUはHyperThreading込で24コアです。そこで動いていたOSはDebianでL
The document discusses Linux performance analysis and tools, focusing on methodologies to identify and resolve performance bottlenecks in operating systems and applications. It emphasizes the importance of understanding system limits to optimize spend and build scalable architectures, while introducing various tools for analysis such as iostat, vmstat, and top. Brendan Gregg, a lead performance en
斎藤です。 今日は、RRDToolを使って、今後かかる負荷を手軽に予測する方法をご紹介します。あわせて、プログラムと連携して性能限界を越えそうなサーバがあるかを判定してみます。人手ではまかないきれない数のサーバに対して、一台ずつ問題の予兆を調べるときなどにお試しください。 ※CentOS 6.3 (64bit) + RRDTool の2013/2/20頃の最新ソースを用いて試しています 「限界」を早く知りたい！ ITインフラを運用している方の多くは、Cacti, Munin等で負荷を日々モニタリングされているかと思います。モニタリングしたデータを用いて今後を予測する際、どのようにされていらっしゃいますでしょうか？描かれたチャートの動きをもとに、経験と勘を駆使して「ヨイショ！」っとされている方も、いらっしゃるのではないでしょうか。 特に、ディスク容量やネットワークトラフィック等、根本的な対策
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
