ソケット通信 possible SYN flooding on port 443. Sending cookies. がログに出てきた - Qiita
ソケット通信 possible SYN flooding on port 443. Sending cookies. がログに出てきたLinux はじめに インターネットに公開しているホームページが突然閲覧できなくなりました。サーバではロードアベレージも低く、負荷はかかっていないようでした。今回の記事ではこの状況下でのボトルネックの確認＆対応方法について簡単にまとめてみました。 環境 CentOS6 Apache 参考 https://qastack.jp/server/294209/possible-syn-flooding-in-log-despite-low-number-of-syn-recv-connections https://github.com/hiboma/hiboma/blob/master/kernel/net/net-backlog.md https://qiit
無線LANの干渉を測れ【前編】
無線LANのパフォーマンスについて、「使用するチャンネルが重なるとパフォーマンスが低下する」「電子レンジを使うと通信速度が低下する」といった話がよく聞かれる。これらの現象は一見まったく異なるものに見えるが、実はその原因はともに「干渉」にある。そこで今回は、無線LANのパフォーマンスに密接にかかわる現象「干渉」について調べてみよう。 速度低下の元凶は「干渉」だ 前回は「無線LANの実パフォーマンスを測れ」と題し、無線LANの公称通信速度と実際の通信速度の差を、IEEE802.11の仕様とともに解説したが、いかがだっただろうか。無線LANではその仕様上、実際の通信速度が公称速度よりも遅くなることは避けられないことを分かっていただけたかと思う。 しかし、実環境においてはさらに無線LANのパフォーマンス低下を引き起こす現象がある。それは「干渉」である。無線LANが持つ複雑な仕様の多くは、すべてこの
Dockerホストのパフォーマンスを引き出すTCPカーネルパラメータチューニング
もう半年くらいフルDockerでmicroservicesなサービスを運用してるんですが、イマイチパフォーマンスを出し切れていないなという面がありまして、今回DockerホストのTCPカーネルパラメータを抜本的に見直しました。 そしたら劇的に症状が改善して、インスタンス数も削減できた上に安定してメシウマ状態になったので紹介します。実際効果があったのでチューニングポイントとしてはある程度正解であったと考えていますが、もちろん扱ってるアプリケーションの特性にもよるはずなので一つのケーススタディであることをご了承頂ければと。 前提 まずは今回のお話の前提を。こんな環境です。 EC2 c3.xlarge ホストはUbuntu（EC2 Optimized AMIは未使用） Docker 1.11.2 MySQL（HAProxy経由）やRedisへのデータストアの通信、各microservicesへの
GoogleのQUICの論文が知見の塊だった - ASnoKaze blog
20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。
ネットワークでなぜ遅延が生じるのか
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
ロードバランサのアーキテクチャいろいろ - yunazuno.log
少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing
光遅い問題を克服してcomposerを10倍速くした話 | メルカリエンジニアリング
はじめまして。サーバーサイドエンジニアの中野(@Hiraku)です。2015年12月からメルカリで働いています。 2016年1月27日(水)の第98回PHP勉強会@東京にて、composerを速くする取り組みについて発表をしてきました。 composerはPHPにおける実質スタンダードなパッケージマネージャです。 このcomposer、日本で実行すると非常に遅く感じます。この原因は普通ならこう表現すると思います。 githubやpackagistが日本から遠いから composerの実装がよくないから しかし発表ではあえて「光が遅いから」という主張をしました。 一般常識として、光の速さ(真空中で秒速約30万km)はとてつもなく速いものという認識だと思います。しかし一方で、地球や宇宙の規模など極限的な状況に携わる仕事をしている人であれば「全然速くない、むしろ遅い」というのが普通の感覚です。
Consulを利用したTLSセッションチケットの自動更新 | メルカリエンジニアリング
Site Reliability Engineering Team（通称SRE）の@cubicdaiyaです。最近チーム名が変わりました。 今回はConsulを利用して複数台のnginxサーバのTLSセッションチケットを自動更新する仕組みについて紹介します。 TLSセッションチケットは簡単に言うとTLSのセッション情報を暗号化してクライアント側に保存することで HTTPS通信時に行われるTLSハンドシェイクの手順を省略してネットワークレイテンシを削減するための仕組みです。(詳細については一番下の参考情報を御覧ください) 似たような仕組みとしてTLSセッションキャッシュがありますが、こちらはセッション情報をサーバ側に保存します。 HTTPS通信ではTCPのハンドシェイクに加えてTLSのハンドシェイクが必要になるのでHTTP通信よりもネットワークのレイテンシが大きくなりますが、 これらの仕組み
muninのRRDファイルの設定情報をのぞいてみた
gistfile1.pl � Ƭ�U �wb��U # Dumper(RRDs::info "/var/lib/munin/test01/test01-cpu-user-d.rrd")の抜粋 # けっきょくのところ # 300秒ごとに監視。保存設定は以下4つ # 1. 2日間、そのまま保存 # 2. 9日間、6回（30分）ごとのサマリで保存 # 3. 45日間、24回（2時間）ごとのサマリで保存 # 4. 450日間、288回（24時間）ごとのサマリで保存 $VAR1 = { # 全体情報 # step（監視感覚）が300 'step' => 300, 'filename' => 'test01/test01-cpu-user-d.rrd', 'header_size' => 2880, 'last_update' => 1356346805, 'ds[42].index' => 0, '
RRDtoolを使う
RRDtoolを使う 久保田 拓朗 takuo@bonz.squares.net 1.1版 2005.02.26 目次 1. RRDtoolについて 2. RRDtoolのコマンドの使い方 3. パイプモード 4. Perlから利用する 5. チューニングについて 6. その他 7. 最後に 2. RRDtoolのコマンドの使い方 3. パイプモード 4. Perlから利用する 5. チューニングについて 6. その他 7. 最後に 1. RRDtoolについて RRDtoolとは • 各種時系列のデータを格納し描画します。 • データはRound Robin Databaseに格納します。 • 作者はMRTGの作者でもある Tobi Oetikerさんです。 • ライセンスはGPL(GNU General Public License)です。 本家 http://people.ee.e
Linux の TCP/IP チューニング・パラメータ
TCP のチューニング・パラメータ 接続確立関係のチューニング・パラメータ TCP のチューニング・パラメータ TCP のチューニング・パラメータは、以下のコマンドで取得できます。 なお、以下は Linux のものです。 >cat /proc/sys/net/ipv4/tcp_retrans_collapse 1 >cat /proc/sys/net/ipv4/tcp_keepalive_probes 9 >cat /proc/sys/net/ipv4/tcp_keepalive_time 10800 >cat /proc/sys/net/ipv4/tcp_syn_retries 10 >cat /proc/sys/net/ipv4/tcp_sack 1 >cat /proc/sys/net/ipv4/tcp_timestamps 1 >cat /proc/sys/net/ipv4/tcp
＠IT：/procによるLinuxチューニング ［後編］（2/4）
/procによるLinuxチューニング ［後編］ ～ /proc/sysの主要パラメータ群総解説 ～ 遠田 耕平 2002/12/17 /proc/sys/fsディレクトリ /proc/sys/fsには、ファイルシステム関連のチューニングパラメータが集められています。 file-max システム中のオープンファイル管理データの最大数を指定できます。 file-nr file-nr内のパラメータはそれぞれ、オープンされているファイル数、空きファイル管理データの数、システム中のオープンファイル管理データの最大数（file-maxと同じ）を示します。 ファイルのクローズ時には、使っていたファイル管理データを即座に解放するのではなく、いったん（次の機会に使えるように）取り置きます。この取り置かれている管理データの数が、2番目の数値となります。 inode-state、inode-nr inode-
バックログの指定 - 揮発性のメモ２
listenのバックログが指定できない - 揮発性のメモの続き http://www.linux.or.jp/JM/html/LDP_man-pages/man2/listen.2.html int listen(int sockfd, int backlog); backlogでバックログの数＝accept()待ちの接続のキューの数を指定できる。 ということになっているけど、実際はキューの数をあまり制限できないっぽい。 カーネル側の設定を # cat /proc/sys/net/ipv4/tcp_syncookies 0 # cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1プログラム側を result = listen( sd, 1 );として制限かけていても、実際にはセッションが確立してしまう。 tcp 0 0 172.16.1.4:5000 1
Webクライアントからの接続数とリクエスト処理スレッド数の制御
ここでは，Webクライアントからの接続数の制御と，リクエスト処理スレッド数の制御について説明します。 インプロセスHTTPサーバでは，一度に接続できるWebクライアントの数を設定することで，インプロセスHTTPサーバで作成するリクエスト処理スレッド数を制御できます。また，処理を実行していないリクエスト処理スレッドを予備スレッドとして一定数プールしておくことで，リクエスト処理スレッドの追加・削除に掛かる処理を最小限に抑えられます。 このように，Webクライアントからの接続数とリクエスト処理スレッド数を制御して，リクエスト処理スレッド数を最適化することによって，J2EEサーバの負荷を一定に抑え，安定した高いスループットを維持できます。 Webクライアントからの接続数の制御とリクエスト処理スレッド数の制御について説明します。 ＜この項の構成＞ (1) Webクライアントからの接続数の制御 (2)
何か決めなきゃ駄目ですか。 Linuxのbacklogについて
少しだけ突っ込んだ話。 （曖昧さは人間の脳内補完に委ねるとして･･･。） LinuxにはTCPの3Wayハンドシェイク（即ち、SYN,SYN/SCK,ACK）状態保持に関連して、 次のようなパラメータを持っている。 net.ipv4.tcp_max_syn_backlog=1024 何それ？って人は # sysctl -a | grep tcp 等のコマンドで探します。 # sysctl -a | grep backlog？それじゃノイズが無さすぎて面白くｎ(ry これは、「LinuxがSYNを受信し、SYN/ACKで応答した状態をいくつ保持するか」というもの。 閾値を超えると、Linuxは新規に接続しようとするホストのリクエスト（SYN）を無視する。 最近のLinuxを、最近のハードウェアにとりあえずインストールすると、 初期値は上記のような1024とか言う数値になっていると思う。 利用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxでネットワーク帯域と速度をモニタリングするコマンド
CloudFrontをかますとキャッシュなしのAPIコールでも速くなるようだ : sonots:blog
負荷分散技術を選ぶときに考えること
はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena
ノンブロッキングI/Oと非同期I/Oの違いを理解する
