10GbE、40GbEなどの極めて高速な通信をサポートするNICが、PCサーバの領域でも使われるようになってきている。 このような速度の通信をソフトウェア(OS)で処理し高い性能を得るには様々な障害があり、ハードウェア・ソフトウェア両面の実装を見直す必要がある。 本セッションでは、ハードウェア・ソフトウェア両面にどのような改良が行われてきており、性能を引き出すにはどのようにこれらを使用したらよいのかについて紹介する。
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
AMIが公開されたのでもう一度やってみた。 AMIについてはこちらのエントリに書かれています ISUCON4 予選問題の解説と講評 & AMIの公開 : ISUCON公式Blog まず ami-e3577fe2 を m3.xlargeで起動します。 CPUは model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz でした。 とりあえず、MySQLのindexを追加する。init.shに追加 $ cat init.sh cat <<'EOF' | mysql -h ${myhost} -P ${myport} -u ${myuser} ${mydb} alter table login_log add index ip (ip), add index user_id (user_id); EOF ベンチマークツールのhttp keepal
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか? SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
https://www.youtube.com/watch?v=FEs2jgZBaQA 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 CSSconf EU 2014におけるGoogleのAddy Osmaniの講演です。CSSのパフォーマンス向上に役立つツールを40個+ 紹介してくれてます。 背景 パフォーマンスの最適化において、 ベースラインとしてやること 最小化(minification) 結合(concatenation) 画像の最適化 圧縮(GZip, Zopfli) 非同期スクリプト キャッシュの利用 WOFF2フォント CSSスプライトを使う リダイレクトをしないこと スピードアップ パフォーマンス向上に重要なCSSのインライン化 レンダリングをブロックしないように、急ぎでないアセットの取
#isucon 4 予選に参加しました(スコア 37513) Posted 2014年10月3日 by はらぐち & filed under インフラ, プログラミング. @memememomo (uchiko) と onihsiと@cs_sonar(僕)で参加しました。 チーム名は「京都スイーツ」です。 結果としては本戦出場はできそうにないスコアで残念でした・・・。 (2014/10/06 追記。失格になってました。) 以下備忘録です。 インスタンス立ち上げ AMI-IDをゲットしてインスタンスの立ち上げ。 全員にそれぞれ検証環境を用意する事を前日話していたのでインスタンス台数は4で一気に立ち上げ。 一つを本番用、他3つをメンバー用。 perlに切り替え superviserd stopしてもrubyのアプリが立ち上がったままだったので なんでやと思いながらも躊躇なくkill
You will get the following errors when your Nginx run out of file descriptor in your log files or on the web browser: nixCraft is a one-person operation. I create all the content myself, with no help from AI or ML. I keep the content accurate and up-to-date. Your privacy is my top priority. I don’t track you, show you ads, or spam you with emails. Just pure content in the true spirit of Linux and
ソフトウェア工学における性能解析(せいのうかいせき)または性能分析(せいのうぶんせき)(英: performance analysis)とは、動的プログラム解析の一種であり、プログラムの実行を通して情報を収集することでプログラムの性能を解析することを言う。逆にプログラムを実行せずに行う解析を静的コード解析と呼ぶ。性能解析の目的は、実行時間やメモリ使用量を最適化するためにプログラムのどの部分を改良すべきかを決定することである(ボトルネック、アムダールの法則参照)。 プロファイラの利用[編集] プロファイラ(英: profiler)は性能解析ツールであり、プログラム実行時の各種情報を収集する。特に、関数呼び出しの頻度やそれにかかる時間を計測する。出力は記録したイベントの羅列(トレース)の場合と、観測したイベント群の統計的要約(プロファイル)の場合がある。プロファイラがデータを収集する技法は様々
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 (このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・) で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
サーバをnetstat -anで様子をみると、TIME_WAITが大部分を占めていた。 これってこのままでいいのか? と思い、TIME_WAITについて調べてみました。 TIME_WAITをなんとかしたい場合は、以下の方法が考えられます。 1, サーバ増強 分散させたり、性能を上げます。あくまで一時的な対応になります。 2, 利用可能なTCPポート番号のチューニング 増加量が上回る場合は、焼け石に水です。 3, tcp_tw_recycleを有効 + tcp_fin_timeout値を短くする。 パケットのタイムスタンプの影響で通信に問題が出てきます。webサーバなどでは新たな障害にも。 4, TIME_WAITの値を60秒→15秒に変更(参考リンク引用) TIME_WAITが減り安定動作するそうです。 以上の4点を順番に見て行きましょう。 注意としてはどれもカーネルパラメータのチューニン
ディスクに書き込む必要があるバッファの最大数 大きくすると、ディスクの書き込みを遅らせます 小さくすると、頻繁にディスクの書き込みを行います
チーム「ご注文はPHPですか?」として @matsuu @do_aki ご両人と共に参加してきました!利用言語はGoです。 結果は初日暫定10位。benchmarkerのバグは利用無し(気付かず)。 本戦出場は・・・大変微妙・・・ →初日5位で通過出来ました!やったね! 最後まで表示されてるピンクが我らです。 最初独走して、その後次々に追いぬかれていくさまが見て取れます。 さくせん 事前に作っておいたツールを使ってアクセスログを集計しながら、 ポイントを絞って重たいものから順番に対処していきました。 勘とか思いつきはぐっと堪えて、やるべきことをやりましょう! ・・・って社内の事前勉強会で言った立場なので、、ね。 やったこと 時系列は覚えていない。和幸のとんかつ弁当が美味かったことは覚えている。 .vimrc goを書く準備(去年の予選AMIで練習してた通りにした) /etc/sysctl.
11:10~ 課題ページの確認&PageSpeed Insightsの実行目的:チューニング対象のウェブサイトの改善の余地を調査 上記のgruntプラグインをインストールする npm install コマンドを実行しながら、ブラウザやIDEでチューニング対象のウェブサイトを確認し始めました。 少し見ただけでもCSSの構文エラーがあったり、使っていないJavaScriptライブラリがインポートされていたり…。 まるで無茶な運用を数ヶ月続けたかのような、カオスなファイル群でした。 ここで実行した PageSpeed Insights に画像サイズの最適化をオススメされたので、まずはそこから行うことにしました。 11:20~ 画像ファイルの最適化目的:画像ファイルサイズの削減 30 x 30pxで表示している画像ファイルが実際には150 x 150pxで保存されていたりする画像がそこそこあったの
TOTEC2014 インフラチューニング(チューニンガソン)で優勝したはなし | サイバーエージェント 公式エンジニアブログ インフラ&コアテク本部の仲山です。 「TOTEC2014 インフラチューニング」という社内チューニンガソンイベントで優勝をいただいたので、 技術ブログを書くことになりました。 TOTECは、サイバーエージェントグループ内の技術者コンテストで、 インフラ、フロントエンド、サーバサイドの分野ごとに、 「チューニンガソン」と呼ばれる形式でその速度向上を競い合います。 今回の「インフラチューニング」では、 参加者はソフトウェアのソースコードを改変できないため、 あくまでミドルウェア等の変更、チューニングや、サーバ構成の最適化のみで闘います。 主なレギュレーション 運営があらかじめ用意したMediaWikiの応答速度を競う。 ソースコードの変更は禁止だが、設定ファイルの編集は
たまにはPowerShell 以外の記事を。 某記事でもRedis (REmote DIctionary Server)が memcached に代わり得る利点がBookSleeveを交えて丁寧に説明されました。 そして、Redisの運用が一定の目途を見せていることから、その初期設定に欠かせないチューニングについて記事にしてみようと思います。 全部明かすわけではありませんが、なかなかRedisに関する記事は少ないので、少し参考になれば幸いです。 経験上、高負荷環境ではRedisはチューニングで大幅に安定性が変わります。 インストール? 沢山記事ありますし、簡単なのでここでは省きます。 どうしても!な場合は希望していただければ記事にしますが。 Redis Quick Start 対象バージョン 2.6系とします。 2.4系でも大方一緒ですが、2.6系に特有な部分があるので、注意です。 対象O
最後に切り戻しミスって圏外で終了という痛い結果になってしまった。その記録。 事の顛末の要約と感想 競技開始 -> そこそこ良いスコアを出す -> phpまわりをいじりだす -> 終了直前までいじってもスコア上がらんので切り戻す -> なぜかスコアが全盛期に戻らないという事案が発生 -> 死 最初ぐだぐだになるんじゃないかと思っていたんだけど、なかなか面白かったです。定期的にこういう企画やると良いと思う。というか、月一くらいで重要サービスのチューニングをお題にしてみんなでチューニング大会したらいいんじゃないかな。会社としても絶対プラスになると思うよね。 競技のルール AWSのインスタンス4台与えられる。 すべてのインスタンスにApache, php, MySQLでアプリケーションが動いている そのうち一台に定期的に負荷が飛んでくるので、その結果がスコアとなる phpのソースはいじっちゃダメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く