Goのnet/httpのkeep-aliveで気をつけること - Carpe Diem
概要 Idle connectionをプールするkeep-aliveの仕組みですが、Goで適切に使用するためにはいくつか注意があります。 環境 golang/go 1.13.1 TCP Keep-Aliveの挙動をパケットキャプチャで確認する 例えば以下のようにDefaultTransportの一部の設定（①、②）をイジってリクエストを送ると client = &http.Client{ Transport: &http.Transport{ DialContext: (&net.Dialer{ Timeout: 30 * time.Second, KeepAlive: 10 * time.Second, // ① DualStack: true, }).DialContext, ForceAttemptHTTP2: true, MaxIdleConns: 100, IdleConnTim
Linux Performance
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
How Okta Chased Down Severe System CPU Contention in MySQL
Check out the free virtual workshops on how to take your SaaS app to the next level in the enterprise-ready identity journey! Sometimes fixing a problem causes or reveals a new one. And sometimes this sets off a chain reaction of problems and fixes, where each solution exposes a deeper issue. In technology, cascades like these are common, often painful, and occasionally welcome. Our battle against
[postgres]大容量メモリかつOSがRHEL(CentOS)6系をお使いの方、THPのdefragは止めた方が良いですよ - Qiita
[postgres]大容量メモリかつOSがRHEL(CentOS)6系をお使いの方、THPのdefragは止めた方が良いですよPostgreSQLCentOS6 概要 とある日、postgresが稼働しているサーバのリプレースを行ったところ、 CPUのsysがスパイクしてpostgresが数十秒ほど処理不可となり、ひどい目にあったという話です。 ※この環境はCentOS6.8で、postgresは9.4でも8.2でも同現象が発生しました 原因は"THP(Transparent Huge Page)"というOSの機能に関連したdefrag(compaction alloc)処理により、CPUリソースが枯渇したためでした。 検証したところ、以下の状況が重なるとsysスパイク現象が起きてしまう様です。 サーバの搭載メモリが大きい(たとえば200GB以上) 継続的にトランザクションが発生する TH
![[postgres]大容量メモリかつOSがRHEL(CentOS)6系をお使いの方、THPのdefragは止めた方が良いですよ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/795590a58a085ffc649793e576dc99186e547126/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCcG9zdGdyZXMlNUQlRTUlQTQlQTclRTUlQUUlQjklRTklODclOEYlRTMlODMlQTElRTMlODMlQTIlRTMlODMlQUElRTMlODElOEIlRTMlODElQTRPUyVFMyU4MSU4Q1JIRUwlMjhDZW50T1MlMjk2JUU3JUIzJUJCJUUzJTgyJTkyJUUzJTgxJThBJUU0JUJEJUJGJUUzJTgxJTg0JUUzJTgxJUFFJUU2JTk2JUI5JUUzJTgwJTgxVEhQJUUzJTgxJUFFZGVmcmFnJUUzJTgxJUFGJUU2JUFEJUEyJUUzJTgyJTgxJUUzJTgxJTlGJUU2JTk2JUI5JUUzJTgxJThDJUU4JTg5JUFGJUUzJTgxJTg0JUUzJTgxJUE3JUUzJTgxJTk5JUUzJTgyJTg4JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0yNjY1N2VmMjgzMWFjMjAzNjUyN2YzMWU2YjU5Y2M4Mg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwTW9yaWhheWEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTRiZmQyYTIxZGEyNmMzMDJlNjFhYzg3Zjk1YzIwMjEy%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D4714812bf897cd530226deb44c3a9d3f)
Redisのslowlog設定 - tsunokawaのはてなダイアリー
概要 Redisのスローログ出力方法と設定のメモ slowlogを5件出力する SLOWLOG GET 5 表示例 [tsunokawa@test ~]$ redis-cli 127.0.0.1:6379> SLOWLOG GET 5 1) 1) (integer) 18284101 2) (integer) 1471441352 3) (integer) 56080 4) 1) "GET" 2) "testkey1" 2) 1) (integer) 18284100 2) (integer) 1471441352 3) (integer) 55133 4) 1) "GET" 2) "testkey1" 3) 1) (integer) 18284099 2) (integer) 1471441352 3) (integer) 43424 4) 1) "GET" 2) "testkey1"
Measuring Intel Hyper-Thread Overhead
Multi-core processors are capable of running multiple software streams/tasks concurrently. Multi-core allows a physical processor to simultaneously execute instructions from multiple processes or threads. Core of a processor is the part that executes application instructions. Core is shared by hardware threads (called Hyper-Threads). When two hyper-threads are active in the same core, it results i
TCP keepalive設定でハーフコネクションを解消
２台のサーバ間がTCPハーフコネクション状態になる事象が発生した。 TCP keepalive(キープアライブ)の設定でその状態を解消するための手段をメモしておく。 ◆ 構成 サーバAとサーバB ◆ アプリケーション仕様 サーバAがサーバB上のファイルを定期的に取得する。 両サーバ間はTCPコネクションを張り続けている。通信ごとに接続する仕様ではない。 ◆ トラブル サーバBに障害が発生し、サーバBが突然ダウンした。 そのためサーバBからサーバAへのTCPのクローズ処理が行われず、 サーバAだけにTCPの状態がESTABLISHEDで残るハーフコネクションとなってしまった。 LANケーブルが抜けた場合なども同じ状態になるだろうか。 ハーフコネクションの有無は、サーバA、サーバBでそれぞれ "lsof -n"、"netstat -an" などのコマンドを打ち、状態がESTABLISHEDにな
ぜんぶTIME_WAITのせいだ！ - Qiita
課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 とりあえず何とかしたい TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.39
AWS Redis on ElastiCache のBenchmark をしてみた - tech.guitarrapc.cóm
実は Redis on ElastiCacheに関しては、先月2013年9月5日に AWSからリリースされてから、すぐにベンチマークをとっていました。 が、記事にするのを忘れていたという、いつもの有様です。 さて、Redis on ElastiCacheに関しては、他にも既にいくつかのベンチマーク記事があります。 まめ畑 - ElastiCache Redis Engineのベンチマークともろもろ インフラ備忘録 - Redis on ElastiCache を試しています Medium - Benchmarking Redis on AWS ElastiCache 今回は、EC2で Redisを実際に高トラフィックで使っている立場から、EC2とRedis on Elastic Cacheを比較したベンチマークを公開します。(他の記事とは違いm2.4xlargeベースの検証です) 目次 目
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
SACSIS.TCP - HPCユーザが知っておきたいTCP/IPの話
HPC TCP/IP 2009 5 29 SACSIS2009 HPC TCP/IP 2 • • 1 Gbps RTT 100 • 240 Mbps ☹ • 940 Mbps ☺ (2) HPC TCP/IP • Ethernet PC • TCP/IP 2 10MB 3 0 200 400 600 800 1000 0 100 200 300 400 500 600 Bandwidth (Mbps) Time (msec) 160 0 200 400 600 800 1000 0 100 200 300 400 500 600 Bandwidth (Mbps) Time (msec) x3.5 (2) • TCP/IP • • MPI • TCP/IP TCP • TCP Reno [RFC2851] • TCP CUBIC Compound TCP 4 (3) • TCP/IP • T
Omicron TCP/チューニング/Linux
TCP/チューニング/Linux TCP/チューニングから分家． ソケットバッファサイズ /proc/sys/net/core/rmem_default, rmem_max /proc/sys/net/core/wmem_default, wmem_max 1ソケットに割り当てられるバッファのデフォルトと最大値のシステムグローバルな値． これらの値は起動時にメモリ量から自動設定される．物理メモリが 16MB 以下で 32KB，16M〜512MB で 64KB，512MB 以上で 128KB． ソケットローカルに設定したい場合は，(setsockopt によって) SO_SNDBUF，SO_RCVBUF ソケットオプションを利用する． ソケットオプションで設定できる上限は rmem_max，wmem_max となる． struct sock の sndbuf，rcvbuf あたりに関係． /
Zend Frameworkを速くするよ
かなり前の話題ですが、PHPのフレームワークのパフォーマンス比較記事がありました。 これを見てわかる通り、Zend Frameworkは結構遅いフレームワークです。昔、リリースされたばかりで機能がショボかったころは速いと言われたりもしましたが、Zend_Applicationが追加されてからは多機能化を突き進んでいて、それに伴って遅くなっています。 そもそもZFのセールスポイントって、「疎結合」「高い拡張性」「品質の高さ」などで、パフォーマンスは優先されていないような気もします。 でも最低限の速さは欲しいので、パフォーマンスチューニングをやってみます。 基本 公式ドキュメントの「Zend Frameworkパフォーマンスガイド」を実践するのがすべての基本になります。 あとはPHPの基本的なパフォーマンスチューニングをやることですかね。とりあえずAPCは導入して、Xdebugで測定して、遅い
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
Mount options to improve ext4 file system performance « SmartLogic Solutions Blog
I recently boosted my rails test suite running time by around 30% by adding certain mount options for my ext4 partition (works for ext3 too). I thought I’d blog about it because the first time I tried my system wouldn’t boot! So here are the step by step instructions: 2) Run: > tune2fs -o journal_data_writeback /dev/sdXY Where /dev/sdXY is replaced by the partition that you want to boost 4) Edit
Manual:Performance tuning - MediaWiki
This page provides an overview of different ways to improve the performance of MediaWiki. Context[edit] MediaWiki is capable of scaling to meet the needs of large wiki farms such as those of Wikimedia Foundation, WikiHow and Fandom and can take advantage of a wide number of methods including multiple load-balanced database servers, memcached object caching, Varnish caches (see Manual:Varnish cachi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How do I get A+ from Qualys SSL, but keep FIPS compliance?
nginxのパフォーマンスチューニング
HPCユーザが知っておきたいTCP/IPの話 ~クラスタ・グリッド環境の落とし穴~
10GbE時代のネットワークI/O高速化
