時にはネットワークの問題である：ある戦いの物語

Chris Siebenmann :: CSpace » blog » sysadmin » SometimesItIsTheNetwork ようこそ、ゲスト。 時には実際にネットワークの問題であることが：ある戦いの物語 2026年7月5日 最近、一部のバックアップのパフォーマンスが低下するという謎の問題を抱えていました。また、最近、 outgoing 1Gインターフェースをトラフィックで飽和させるWebサーバーがあったこと（そして、より高速なネットワークリンクがないことが機能であったこと）について書きました。これら2つのことは、私たちが望むほど無関係ではありませんでした。そして、そこには1つか2つの物語があります。 問題のバックアップは、通常のAmandaベースのバックアップシステムを通じて行われるものではありません。代わりに、特定のセントラルマシンがFreeBSDおよびOpenBSDホストから/var/logなどの関連ファイルを（rsyncまたは直接SSHアクセスを通じて）プルし、それをNFS経由でNFSファイルサーバーに書き込みます（その後、Amandaバックアップによってバックアップされます）。問題はひどいNFSパフォーマンスとして現れました。セントラルマシンのロードアベレージは50または70になり、NFS関連のすべてが遅くなり、といった具合です。 一般的にNFSは好きですが、NFSにはかなりの問題（cf、also）を抱えてきたため、すぐにこれがNFS問題の別の事例であると仮定しました。まず、さまざまな方法でrsyncからのIO負荷を軽減しました（eg）。次に、メトリクスシステムと問題発生中のライブシステムの両方から、さまざまなNFSメトリクスを調査するのにかなりの時間を費やしました。問題は何も見つかりませんでした。ファイルサーバーは完璧に良いパフォーマンスを持っていましたが、マスターマシンはひどい実際のNFSパフォーマンスを持っており、特にバックアップデータを毎秒数MBの範囲でしか高速に書き込めませんでした。 セントラルマシンはローカルディスクに許容できる速度で書き込めると確信していたので、より複雑なバックアップスキームに切り替えることを検討しました。まずローカルディスクにrsyncし、このディレクトリツリーをtarアーカイブにパックしてから、関連するファイルサーバーにscpで送信し、NFS書き込みの問題を回避するというものです。これが許容できる速度で機能するかどうかを確認するために、まずセントラルマシンからファイルサーバーにテストファイルをscpで送信しました。驚いたことに、scpは毎秒約2MBしか実行されませんでした。さらなるテストで、このセントラルマシンからどこへでもscpは最大で毎秒2MBで実行されることが示されました。これは、NFS書き込みの問題（サーバーの電源が入らないことに対するCPUの欠如と同様）を説明するのに十分でした。 この時点で、私の頭の中で何かが閃きました。私たちは大学の学部であり、必ずしも最新で最も輝かしいものを持っているわけではなく、長期間サービスを維持しています。私たちがサービスを維持してきたものの一つは、基本的な1Gスイッチです。なぜなら、かなりの数のサーバーは1G以上を必要としないからです（そして前述のように、時にはサーバーが1Gしかないことが機能なのです）。しかし、「基本的な1Gスイッチ」と言うとき、私はそのすべてのポートが1Gであるスイッチを意味します。これには、それらを全体的な10Gスイッチファブリックに「アップリンク」するために使用するポートも含まれます（現代の1Gスイッチの多くは、10Gで実行できる1つまたは2つのSFP+ポート、または1つまたは2つの10G-Tポートを持っているのとは対照的です）。これは、通常の1Gサーバーにとっては問題ありません。それらは、集計してもほとんどトラフィックを生成または受信しないためです。しかし、そのようなスイッチに高負荷の1Gサーバーを接続すると、すぐにひどく問題になります。たとえば、私たちの新しい高負荷Webサーバーは、自身の outgoing 1Gインターフェースを飽和させていただけでなく、接続されていたスイッチの1Gアップリンクも飽和させていました。そして、残念ながらこの重要なセントラルマシンもそのスイッチに接続されていました。 プログラマーは、コンパイラバグがあると思っても、それはバグではなく、まだ見つけていない通常のバグであると言います。この言葉はほぼ常に真実であり、カーネルバグ（also）やハードウェアの問題、ネットワークの問題など、他の分野にも一般化できます。私たちの規模では、現代のネットワークは信頼性が高いため、明白な問題がない場合（たとえば、監視システムが予期せず100MBit/secで動作しているマシンを警告していない場合）、ネットワークはほぼ確実に正常に動作しています。そのため、数日間、実際に確認することは思いつきませんでした。もちろん、ネットワークは正常に動作していました。ネットワークは常に正常に動作しています。明らかにNFSが原因であるはずでした。特に、過去にNFSが不安定だったことがあるからです。 しかし、時にはネットワークが問題であり、それに気づけば明白になる良い説明さえあるのです。この経験全体から、私に考えさせられることがいくつかありました。一方では、数年前に、明白な問題が必ずしも明白ではないことについて書きました。数多くの問題があり、何とかしてそれらを絞り込む必要があります。他方で、もし私たちが最初から体系的なトラブルシューティングを行っていれば、かなり早期にこれを見つけられたと確信しています。たとえば、USEメソッド（Usage, Saturation, Errors）を使用していれば、使用状況、飽和度、そして特に「エラー」を確認することになり、セントラルマシンでのTCP再送信（明らかに高かった）に目を向けることになったかもしれません。 トラブルシューティングを体系的に行うことは一般的に良いことですが、同時にそれは退屈です。もし問題が本当にNFSの問題（過去にあったように）であり、私が最初からUSEメソッドに従っていたら、両方のマシンでネットワークが正常に動作していることを確認するのにかなりの時間を費やしていたでしょう（私が調べた他のこと、例えばNFSサーバーのメトリクスと一緒に）。おそらく私が試すべきことは、最も可能性の高い推測から始めることです。そして、それらが的外れになったとき（例えば、NFSパフォーマンスの問題の明白な理由がない）、そして私がフラストレーションを感じているとき、USEメソッドまたはそれに類するものに立ち返ることです。たとえそれが退屈であっても。 (2件のコメント) 2026年7月5日に執筆。 « バッファサイズ（OpenSSH）sshはストリーミング出力に何を使用するか Webサーバーのoutgoing帯域幅を制限するためにLinux tcを使用する » これらは私のWanderingThoughtsです（ブログについて） 完全なインデックス 最近のコメント これはCSpaceの一部であり、ChrisSiebenmannによって書かれています。 Mastodon: @cks Twitter @thatcks * * * カテゴリ: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web また: (サブ)トピック これはDWikiです。 GettingAround (ヘルプ) 検索: ページツール: ソースを表示。 検索: ログイン: パスワード: 最終変更: 2026年7月5日 日曜日 22:13:18 このちっぽけなwikiは、Insane Hackers Guild、Pythonサブブランチによって提供されています。