SMBは「遅い」と主張した

私たちの会社のネットワーク（サーバー2008で実行されているWindowsドメインであると私は信じています）は非常に遅いです。これの主な例は、SMBを介してファイルをコピーすることです。リストには数分かかり、適度なサイズのファイルをコピーする場合でもさらに時間がかかります。この問題について近づくと、ITマネージャー（他のメリットがあるにもかかわらず、非常に頑固で技術的な担当者ではありません）は手を挙げて、非常に防御的になり、耳を傾けようとする代わりに言い訳をします。問題の根本原因を解明します。

さて、この問題の人間的要素が解決するのにいくらかの時間と努力が必要であることを認識して、私は彼の言い訳を技術的に反論する方法をまったく知らないままにされています。この場合、彼はSMBが問題であり、「遅い」プロトコルであると主張しています。この声明の証拠はありますか（私は逸話的な反証しかありません）？この議論で前進するための最良の方法は何ですか？

SMBは他の一部のファイル共有プロトコルよりも低速であり、他の一部のファイルよりも高速である可能性があります。しかし、それは重要な部分ではありません。

その質問/議論をする代わりに、そこから先に進む方法を見つけて、SMBが想定されているのと同じくらい速い（または遅い！）かどうかを尋ねることができますか？たとえば、サーバーとワークステーションの間でFTPを使用してファイルを転送すると、パフォーマンスが低下し、パフォーマンスが著しく向上しますか？

ベンダーは、Windowsがインストールされている、ファイルサーバーのパフォーマンスについて説明しているハードウェアのレビューを紹介することができます。

私の経験では、SMBはネットワーク上で「十分な速度」を超えています。サーバー間で10 Gbのネットワークを実行しており、SMBを使用したファイルサーバーのパフォーマンスに非常に満足しており、1 Gbと10 GbのどちらのNICを使用するかに応じて、同じハードウェアで良好なパフォーマンスジャンプを測定しました。SMBは私たちにとって問題ではありません。

私は確かにあなたのネットワーク上の他のものを見ています-インフラが古くなっていて、それが最適に構成されていますか（たとえば、サーバーネットワークカードはすべて最新のドライバーに対して正しく構成され、可能な限り最高の速度で適切に動作しています）、DNSのようなものです-適切に構成されたすべてのネットワークで、スローダウンを引き起こす「ジャンク」トラフィックがたくさんありますか？過度に妄想的な方法で構成されたアンチウイルスです（これにより、衝撃的なスローダウンが発生するのを確認しました）。

ファイルサーバーのパフォーマンスを低下させる原因はたくさんありますが、プロトコルの選択はほとんどありません。

SMBよりも高速なプロトコルがありますが、本質的に遅いわけではありません。

ただし、飽和したサーバーや飽和したセグメントなど、他のプロトコルよりも外部の影響を受けやすい可能性があります。

多くの企業の通常のオフィスネットワークは、近年見られるインターネットとイントラネットのトラフィックの大幅な増加を考慮に入れてアップグレードされていないため、私がギャンブルの男だったとしたら、あなたのネットワークは再設計または何らかの投資で何とかできると思います。また、サーバーを最大限に活用するために、サーバーの交換または手直しが必要になる場合もあります。

どちらの方法でも、直接の原因がSMBであることにあまり重点を置かないでください。不良/古いネットワークとサーバーキットのフォールガイになりそうです。

NFSやFTPなどよりも（転送のための）オーバーヘッドが大きくなります。大きなディレクトリのファイル一覧には時間がかかる場合があります。これには、SMBによるもの、NTFSによるもの、エクスプローラのさまざまなバージョンやインストールされているソフトウェアがクライアント側から実行できる愚かなことが原因です。ファイルベースのデータベース（Access、PSTファイル）などの特定のものは、遅延（WAN）リンクを介して開かれるべきではありません。遅延がうまく処理されないためです。

そうは言っても、あなたが説明する操作は長い時間をかけてはいけません。たぶん、ファイルサーバーは能力不足です。たぶん、会社は標準インストールの一部として、物事を遅くするいくつかのソフトウェアを持っています。ウイルススキャナーの設定が間違っている可能性があります。ウイルスがあるのか​​もしれません。たぶん、あなたとサーバーの間に知らないWANリンクがあるのか​​もしれません。

1. エクスプローラーではなくコマンドラインからファイルを表示すると、ファイルのリストが速くなりますか？
2. コピーはどうですか？
3. 問題のサーバーをデスクトップからpingします-待ち時間はどれくらいですか？
4. tracerouteを実行します-あなたとサーバーの間にはいくつのホップがありますか？

残念ながらNateは、PHBを直接処理することはできません。ここでの最初の防御線は、たとえば、SMB転送とNFSの比較などの実際のメトリックです。

議論を裏付ける実際の数値または統計が得られたら、人間の要素をそれほど扱う必要はありません。統計によると、「問題がどこにあるか、そしてここに証明がある」という。それはあなたの主張です。

まったく絞り込めますか？同じサブネット上のサーバー間転送のほうが良い結果が得られますか？あるクライアントから別のクライアントへの転送はどうですか（\\client\c$→ \\client\d$）？

デュプレックスのミスマッチと同じくらい単純なものを見つけるかもしれません。

これは古いことですが、考慮すべき非常に重要な要素はディスクI / Oです。専用メモリを備えたハードウェアベースのRAIDカードとは対照的に、ソフトウェア/マザーボードRAIDが原因でディスク書き込みパフォーマンスが非常に遅い場合。

ネットワーク負荷が要因ですが、システム管理者がリソースモニターを見て、ボトルネックがどこから発生しているのかを調べ、[概要]タブを調べて、CPU、ネットワーク、ディスクI / O、メモリなど全体を表示するのが最善の方法です。この観点から、ディスクI / Oで消費されている原因となるプロセスまたはプロセスのセット、またはメモリリーク（SQLServer.exe-SBSMonitoringインスタンス）などがあるかどうかを確認できます。帯域幅、そのプロセスを確認し、そのプロセスに関連付けられているホストの数とホストを調べます。これは、3389でのRDPへのハッキングの試みの多くになる可能性があります。これまでの事例と私たちの解決策は、直接のRDPアクセスを削除し、エンドリモートユーザーをVPNにシフトすることでした。

お役に立てれば！