somaxconnの上限値は65535
Linuxのネットワークパラメータの一つに、net.core.somaxconnというのがあります。これはlisten(2)の第二引数backlogの上限値となっています。このsomaxconnは一見intに見えますが、実はunsigned shortの範囲の数値しか受け付けません。それを超える数値を入れると黙って切り捨てられます。つまり -1→65535 0→0 65535→65535 65536→0 65537→1 と同じような動作を内部的にします。なので、この値は絶対に0～65535の範囲を超えてはいけません。以下、詳しい説明です。 おことわり: この仕様はLinux 3.11以降変更されており、範囲外の数値を設定できないようになっています。ここに書いてある内容が再現するのは、Linux 3.10以前の古いカーネルのみです。 まずsysctlの定義ですが net/core/sysct
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Linux SYNパケット取りこぼし - LowPriority
Linuxで負荷も問題になるほど高くなくlisten及びsynのbacklogも溢れてないのに 特定のホストからのみSYNを吸い込んでSYN-ACKを返さない事がある場合があった。 必ず吸い込むというわけではなく、一発で通る場合と数回再送受けてから処理するのも あったりして謎な感じ。tcpdumpで見てもパケット単位の不整合は特に見あたらない。 受け付けている環境で変更されていたTCPパラメータは以下で、syncookies以外は IN/OUTどの部分の処理に関わるのかDocument読んでも良く解らないので、それぞれに ついて参照箇所を調べてみた。(PATHはKERNELのnet/以下) net.ipv4.tcp_tw_reuse (sysctl_tcp_tw_reuse) Outbound Connectionだけ影響 ipv4/tcp_ipv4.c:tcp_v4_connect ip
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
netstatコマンドを使いこなす ＠IT：Windows TIPS -- Tips：
TCP/IP関連のトラブルシューティングを行う場合に、必ずといってよいほど使うコマンドとして「netstat」コマンドがある（実行ファイル名はnetstat.exe）。このコマンドは、主にTCPの通信状態を調べるためには必須であり、ぜひともその使い方をマスターしておきたい。 netstatの基本――通信中のTCPコネクションの調査 netstatコマンドの最も基本的な使い方は、通信中のTCPコネクション（TCP接続）の状態を表示させることである。このコマンドを実行すると、ローカルPCのTCP/IPプロトコルスタック上において、現在アクティブになっているTCP通信の状態を表示できる。 ●「TCP」とは？ 「コネクション」とは？ TCPとは、2つのアプリケーション間で、信頼性のある通信路（コネクション）を開設し、お互いにデータなどをやりとりするための機能である。通信するアプリケーションは、同一
[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority
前回の続き。 パケット自体を零さずに処理に入った後にSYNを落とすのは以下3パターン。 syncookie無効時にsynのbacklog(tcp_max_syn_backlog)が溢れている listenのbacklogが溢れている(3way-handshake完了後のaccept待ち接続) net.ipv4.tcp_tw_recycleの制限に抵触 で、今回問題になっていたのは最後のtcp_tw_recycleへの抵触だった。 現象として発生しうるのは、以下の条件をすべて満たす場合 サーバ側でnet.ipv4.tcp_tw_recycleが有効 TCPタイムスタンプオプションを使用 同一IPからの接続でセッションを跨ぐとセットされるTCPタイムスタンプの値が戻る場合がある 最後の条件が微妙だが、TCPタイムスタンプの値としてセットされる値は起動時を 起算時にしていたりと実装によって初期値
![[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority](https://cdn-ak-scissors.b.st-hatena.com/image/square/264702d4cb37ced3c2fd5dda6a1368c235356862/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127119925553%2F17680117127119930188%2F1557218483)
TCP TIME WAIT の状態を短くする方法
apache bench で負荷をかけたあと、netstat を確認したら、すごい量の TIME WAIT がたくさんあった。 ソケットがひらけなくなっちゃう。。。 で、/proc/sys/net/ipv4/tcp_tw_recycle を 1 にすると TIME WAIT の時間を短縮できるみたい。 デフォルトは 0 。 - テスト arizona ( apachebench ) --- araska ( httpd ) [root@arizona ~]# cat /etc/fedora-release Fedora release 11 (Leonidas) root@alaska:~# cat /etc/lsb-release DISTRIB_DESCRIPTION="Ubuntu 9.10" root@alaska:~# cat /proc/sys/net/ipv4/tcp_tw_
中〜大規模サーバーを運用するときの勘所 – iptablesとip_conntrack – cyano
前回まではmod_proxy_balancerで中〜大規模サーバーを運用するときの勘所をお話ししてきました。 これ以外にもmod_proxy_balancerな中〜大規模サーバーで気をつけるべき点はあります。それがiptablesとip_conntrack。 外部に直接晒されているサーバーはセキュリティーを確保するためにiptablesなどのファイヤウォールを導入しているかと思います。アクセス数がある程度以上になってくると、そのファイヤウォールが思わぬ足かせになってしまうと言うお話です。 iptablesはパケットフィルタリングを行うソフトウェアです。PCに入ってきたり、逆にPCから出て行くパケットを監視し、ルールに従い適宜フィルタリングを行います。 さて、iptablesでは、関連したパケットを追跡するために/proc/net/ip_conntrackというファイルを作り、パケットの情報
vnStat - a network traffic monitor for Linux and BSD
Since vnStat doesn't have/need a fancy GUI, all 'screenshots' are console captures. Examples of the image output can be found from the cgi demo page. $ vnstat --help vnStat 2.12 by Teemu Toivola -5, --fiveminutes [limit] show 5 minutes -h, --hours [limit] show hours -hg, --hoursgraph show hours graph -d, --days [limit] show days -m, --months [limit] show months -y, --years [limit] show years -t, -
Kung Noi:OpenSwanでl2tp IPsec VPN環境
OpenSwanとは OpenSwanとはLinuxでのIPsec実装となり、FreeS/WANの後継プロジェクトとなる。 l2tp IPsecとは l2tpとはレイヤー２でカプセリングしVPNを構成をするプロトコル。ちなみに、カプセル化自体はIPsecのトンネルモードを使用すれば可能。つまり、l2tp IPsecじゃなく、IPsecのみでもVPN環境は可能。WindowsはIPsecも可能だが個人的に使い勝手が気に入らないのでl2tp IPsecを使うことにした。 IPsecとはデータの暗号化。IPsecの実装は複雑でまだ完全に仕様が決まっていないと思う。IPsecについて細かいことは、いろんなサイトで細かい説明があるのでそれを参照してほしい。 ネットワーク構成 クライアントはWindowsでVPNソフトはOS標準を使う。クライアントはNAT配下にあり、サーバはグローバルをもつ。以下の図
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ln-lab.net/lunar-night.lab/page2-memo_vpn/design-white/lang-ja
よくあるご質問｜Red Hat Enterprise Linux｜サイオステクノロジー株式会社
SNMPによるネットワークシステムの監視第1回：SNMPの基礎