第10回ペパボテックカンファレンス~インフラエンジニアがもっとおもしろくできる!~ https://pepabo.connpass.com/event/69866/
rmコマンドで大量のファイルを削除しようとするとjournaldがめっちゃリソース持っていく件— bokko (@cubicdaiya) 2017年8月3日 今時のファイルシステムはみんなジャーナルもってて何かあったときにそこからリカバリする仕組みになってるので、当たり前といえばそうなんだけども。 (TODO: ここにファイルシステムのツリー+ジャーナルのポンチ絵を手描きでも何でも描く) ご本尊のデータのツリーと何らかのWALを1セットで持っておくのはRDBだろうがファイルシステムだろうがそうは変わらない、で、削除についても並行制御をうまくやるために削除フラグをログに入れておいてあとで本尊のデータを整理するというのが基本的な設計になる。そこで私は立ち上がった(TL;DR: 特にオチとかはないです)。 rm -rf が遅いのは人類にとって損失ではないか。もっと速く完了するようにすれば、 rm
動的解析ツール構築のためのフレームワーク「Valgrind」開発チームは10月24日、「Valgrind-3.12.0」を公開した。メモリ監視機能の強化などが行われている。 Valgrindは多数のメモリ管理とスレッドのバグを自動的に検出し、プログラムをプロファイリングするツールを集めたフレームワーク。メモリエラー検出やスレッドエラー検出、キャッシュとブランチ検出プロファイラ、コールグラフ生成キャッシュ、ブランチ予測プロファイラ、ヒーププロファイラなどのツールを備え、Linux(x86、AMD64、ARM、ARM64、PPC32、PPC64、PPC64LE、S390X、MIPS32、MIPS64など)、Solaris(x86、AMD64)、Android(ARM、ARM64、x86、MIPS32)、Darwin/Mac OS X 10.10(X86、AMD64)などをサポートする。 Val
注: 無線ネットワークは干渉などによりこの数値より遅くなる状況も十分ありえます。 ポイント メモリからの読み込みとディスクからの読み込みはランダムアクセスで1000倍程度違う とは言え、最近はディスクも結構速い きちんと繋がれた有線ネットワークからの読み込みは、ディスクより速い つまり、ディスクから読むより、同じデータセンターのマシンのメモリから読んだほうが速い モバイルネットワークだと100キロバイトのデータでも1秒以上かかることがある メモリからの読込速度の遅さは、CPUのクロック数も10G/s程度なのと、本来はL1/L2キャッシュなどがあることを考えると通常意識しなくて良い 何故この参考値をまとめたか プログラミングをする際、どのくらいの時間でどのくらいのサイズ感の処理が出来るのかを考えられることが、ある一定規模以上のサービスを開発するときは必須条件になってくると思います。 なにより
More than 5,000 companies count on our digital courses and more to guide their teams through the tools and technologies that drive business outcomes. We can help yours too. New AI policy for O’Reilly authors and talent O’Reilly president Laura Baldwin shares the company’s ethical approach to leveraging GenAI tools and ensuring O’Reilly experts are compensated for their work. See it now It’s time t
Broken benchmarks, misleading metrics, and terrible tools. This talk will help you navigate the treacherous waters of Linux performance tools, touring common problems with system tools, metrics, statistics, visualizations, measurement overhead, and benchmarks. You might discover that tools you have been using for years, are in fact, misleading, dangerous, or broken. The speaker, Brendan Gregg, has
Last week during a casual conversation I overheard a colleague saying: "The Linux network stack is slow! You can't expect it to do more than 50 thousand packets per second per core!" That got me thinking. While I agree that 50kpps per core is probably the limit for any practical application, what is the Linux networking stack capable of? Let's rephrase that to make it more fun: On Linux, how hard
Video: https://www.youtube.com/watch?v=FJW8nGV4jxY and https://www.youtube.com/watch?v=zrr2nUln9Kk . Tutorial slides for O'Reilly Velocity SC 2015, by Brendan Gregg. There are many performance tools nowadays for Linux, but how do they all fit together, and when do we use them? This tutorial explains methodologies for using these tools, and provides a tour of four tool types: observability, benchma
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 »
isucon3の本戦にLINE選抜チームとして出た。ガッカリな感じだった予選時の状況はこちら。 isucon3予選参戦の記録 - tagomorisのメモ置き場 引き続き @kazeburo @sugyan @tagomoris の3人チーム。 ざっくりまとめ みんなこれまでこんな楽しいイベントに参加してたのか! ずるい!!!!!! 普段やってることを普段通りやる、と思っていたが焦って普段やらないようなミスを次々連発、社会は厳しい 思いきった構成変更とかできるのがisuconでしょwwww とかドヤ顔していたが、やりきれた。ドヤッ。 これからisuconという名前を口にするときに堂々とドヤ顔しようと思います。嘘です。元出題者のくせに成績出ないとかwwwみたいにならなくて本当に安心しました。終わったあとのビールおいしかったです。 ということで、勝ちました。優勝と、あと僅差で特別賞もいただきま
ツチノコブログの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
Introduction Coarse grain timing with time Fine grain timing with a timing context manager Line-by-line timing and execution frequency with a profiler How much memory does it use? IPython shortcuts for line_profiler and memory_profiler Where’s the memory leak? Which objects are the most common? Which objects have been added or deleted? What is referencing this leaky object? Effort vs precision Ref
このシリーズはHTTPリクエストの理解を通じてWebパフォーマンスの重要性について考える5章構成になっている。 【序章】HTTPリクエストは甘え 【CSS Sprite編】スプライト地獄からの解放 【WebFont編】ドラッグ&ドロップしてコマンド叩いてウェーイ 【DataURI編】遅延ロードでレンダリングブロックを回避 【終章】我々には1000msの猶予しか残されていない 1日目は、HTTPリクエストの概要について説明する。 例えに、私のポートフォリオページ(t32k.me)が表示されるまでの流れを見ていく。まず、検索からでも方法はなんでもよいが、ブラウザのURLバーにt32k.meと打ち込んでアクセスする。そのページを見にいくということは、つまりt32k.meに対してHTTPスキームでリクエストするということを意味している。 クライアントであるブラウザは入力されたURLを判断して、リソ
斎藤です。 今日は、RRDToolを使って、今後かかる負荷を手軽に予測する方法をご紹介します。あわせて、プログラムと連携して性能限界を越えそうなサーバがあるかを判定してみます。人手ではまかないきれない数のサーバに対して、一台ずつ問題の予兆を調べるときなどにお試しください。 ※CentOS 6.3 (64bit) + RRDTool の2013/2/20頃の最新ソースを用いて試しています 「限界」を早く知りたい! ITインフラを運用している方の多くは、Cacti, Munin等で負荷を日々モニタリングされているかと思います。モニタリングしたデータを用いて今後を予測する際、どのようにされていらっしゃいますでしょうか?描かれたチャートの動きをもとに、経験と勘を駆使して「ヨイショ!」っとされている方も、いらっしゃるのではないでしょうか。 特に、ディスク容量やネットワークトラフィック等、根本的な対策
[対象: 上級] ページの表示速度が、Googleのランキングを決める指標として日本を含むインターナショナルで導入されていることがSMX Advanced Seattle 2012で判明しました。 そこで今日は、ウェブページの高速化を取り扱ったセッションをレポートします。 スピーカーは、ECサイトのREIでSEOに携わるJonathon Colman(ジョナサン・コールマン)氏です。 ウェブサイトのパフォーマンス最適化 サイトを高速化する理由 コンバージョン率の最適化 カスタマーエクスペリエンスとカスタマー満足度の向上 直帰率を下げる。 競争率が非常に激しいキーワードでオーガニックからのトラフィックを増やす。 全体的な競争力を高める。 運用費を節約する。 数字で見るページスピード Googleではページスピードが検索の1%に影響している。 ユーザーがページ表示に待てるのは2秒まで。 3秒以
What every programmer should know about memory, Part 1 [Editor's introduction: Ulrich Drepper recently approached us asking if we would be interested in publishing a lengthy document he had written on how memory and software interact. We did not have to look at the text for long to realize that it would be of interest to many LWN readers. Memory usage is often the determining factor in how softwar
GrowthForecastがMySQL対応したきっかけとしてSQLiteのdead lock問題があったのですが、PRAGMAでチューニングするとパフォーマンスが結構変わることがわかったのでメモ。 やったのは、journal_mode と synchronous の変更。それぞれ > PRAGMA journal_mode = DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF > PRAGMA synchronous = 0 | OFF | 1 | NORMAL | 2 | FULL のような感じで変更できる。 それぞれの設定は、 PRAGMA Statements - synchronous PRAGMA Statements - journal_mode をみるのが良いと思う。journal_mode に指定できるWALについては次のペ
What is Tsung ? The purpose of Tsung is to simulate users in order to test the scalability and performance of IP based client/server applications. You can use it to do load and stress testing of your servers. (Definition coming from the Tsung website) In this post, I will introduce the use of Tsung in order for you to stress test your web applications. Why Tsung ? Because it’s an Open-Source proje
WEBサイトに情報を入力するだけで負荷テストができるLoad Impact、GUIから操作できるApache JMeterや、コマンドラインから使うcurl-loader・httperf・Siege・Pylot・abを簡単な使い方と共に紹介していきます。 Load Impact http://loadimpact.com/ Load ImpactはスゥエーデンのGatorhole AB社が管理している、フォームに必要な情報を入力するだけで負荷テストをしてくれるWEBサイトです。 ツールをインストールしたりする必要が有りませんので、非常に楽です。 毎月5回まで無料で負荷テストができます。 それ以上は10回/$30のクレジットを購入する事になります。 トップページのフォームにURLを入れて「Run free test」をクリックすると、世界各地のいずれかのAmazon EC2サーバから負荷テス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く