SolarisからLinuxに切り替えると、バックアップ速度が80％削減されます。古い速度を取り戻すのを手伝ってくれませんか？
最初に環境の概要：
LTO3ドライブを搭載したWindowsServer（必要に応じて6.5.4）で実行されているNetBackup。
バックアップターゲットは、Veritas VolumeMangerを備えたSunハードウェア上のSolaris9サーバーでした。
LVMを使用してボリュームを管理するRHEL5ボックスとして再構築され、現在はXiotechSAN上にあります。ボリュームが多い。
ボックスが実行するデータとアプリケーション（Optix）の性質上、特定のサイズに達するまでボリュームに書き込みを行った後、そのボリュームは永久にロックされていました。したがって、\ u01\u02\u03 ...\u50があります。しばらく前に（まだsolarisビルドで）、これらのボリュームを拡張して開いて書き込み用に戻したため、特定の日にいずれかまたはすべてが変更される可能性があります。バックアップスループットは、平均40MB /秒でした。
新しいLinuxビルドでは、平均して8MB /秒に近い値になっています。ここに2.1TBのデータがあることを考えると、これは非常に受け入れがたいものです。4つのストリームを実行していても、完了するまでに48時間以上かかります。サーバーのI/Oが固定されています。同じクラスのストレージと同様のサーバーハードウェアを使用している他のクライアントは、ポーキーであるが許容できる20MB /秒でバックアップしているため、SANではないことは間違いありません。
スループットを向上させるためのアイデアを探しています。隣のオフィスにいるSolarisの人たちは、Linux上のLVMを非難しています。それが他のどこでも期待通りに機能しているので、誰もそれがバックアップ環境だとは思いません。今では非常に遅いボックスの管理者は、「それが私ではないことを知らない、ユーザーはそれでいいと言っている」と言っています。これはおそらくドキュメント管理システムであり、小さなファイルの読み取りと書き込みを行っているためです。
トラブルシューティングのアイデア？ LVMのゴミ箱のバックアップやその他のI/Oパフォーマンスを見た人はいますか？特に、非常に多数（おそらく1,000万）の小さなファイルを保持するボリュームの数が多い場合はどうでしょうか。
単位を修正するために編集。
追加するために編集：
NICは1000 /フルです（OSとスイッチの両方から確認）
ファイルシステムはEXT3です。
より多くの新しい情報...
パフォーマンスへの影響は、LVMとEXT3を実行しているいくつかのボックスで発生しているようです。基本的に、この夏に作成したすべての新しいRHEL5ボックス。
この問題は、Linux/LVMの問題ではなく、NetBackupクライアントのバージョンの問題であることが判明しました。ボックスがLinuxボックスとして再構築されたとき、6.5クライアントがインストールされました。本日、別の問題に対応して、クライアントバージョンを6.5.4にアップグレードしました。 25〜27mb /秒でデータをボックスからプルすることに戻りました。
NetBackupの一番のルール、またはおそらくバックアップソフトウェアを忘れてしまった可能性がありますクライアントとサーバーのバージョンが一致していることを確認してくださいわからない問題が発生した場合。多分私はタトゥーが必要です。
Sarまたはiostatを使用してバックアップ中のディスクパフォーマンスを監視し、Linuxがディスクパフォーマンスについてどのように考えているかを確認しましたか？
ある種のベンチマークユーティリティを使用して、システム上のファイルの生の読み取りパフォーマンスをテストするのはどうですか？私はこれを思いついたばかりなので、これはおそらくこれを行うためのひどい方法であり、これは実際には連続して読むためのものですが、
Sudo dd if=/u1/some_large_file of=/dev/null
基本的に、ベンチマークユーティリティを使用してすべての小さなファイルの読み取りを複製する場合、それがディスクである場合は、そこから実行できます。
以下は関連しなくなりました：
20 kb/sの場合、キロビットを意味します。早朝であるためにこれを台無しにしない限り、数値は合計されません。 20 kb/sで2.1テラバイトあるとおっしゃいました。
たった1テラバイトだったとしても：
1 TB = 8589934592 bits
8589934592 / 20 (bits a second) = 429496730 seconds
429496730 / 60 (seconds) = 7158278 minutes
7158278 minutes / 60 = 119,304 Hours
119,304 / 24 = 4971 (Days)
または、キロバイトを意味する場合：
1 terabyte = 1073741824 kilobytes
1073741824 / 20 kB/s = 53687091 seconds
53687091 seconds = 621 days
私はこれらの計算を台無しにしていますか？ （私がいる場合は恥ずかしくて私の投稿を削除する必要があります:-)）
lVMボリュームでどのファイルシステムを使用していますか？
また、1,000万個の小さなファイルはどのように保存されますか？すべて1つのディレクトリ（または少数のディレクトリ）に保存されますか、それとも多くのディレクトリとサブディレクトリに分散されますか？ （「多く」は任意の数です）
私が尋ねる理由は、何千ものファイルが含まれていると、一部のファイルシステムで深刻なパフォーマンスの問題が発生するためです。これは、速度低下の1つの考えられる原因です。
たとえば、dir_index機能がオンになっていないext2またはext3（IIRC、dir_indexはここ数年ext3のデフォルトになっています。これは大いに役立ちますが、問題を完全に排除するわけではありません）。
tune2fsを使用して、ext3のdir_index機能を照会および/または設定できます。例えばクエリするには：
＃tune2fs -l/dev/sda1 | grep機能 ファイルシステム機能：ext_attr resize_inodedir_indexファイルタイプsparse_super
そのリストにdir_indexが表示されない場合は、次のようにオンにする必要があります。
設定するには：
＃tune2fs -O dir_index /dev/sda1 tune2fs 1.41.8（2009年7月11日）
（はい、tune2fsはバージョン番号を出力することによってのみここで応答します...操作が成功したか失敗したかをわざわざ教えてくれません。良くありませんが、失敗した場合はおそらくエラーを出力します）
最後に：これが問題であることが判明し、dir_indexを有効にしても効果がない場合は、おそらく別のファイルシステムの使用を検討する必要があります。 XFSは優れた汎用ファイルシステムであり、AFAIKext4にはこの問題はありません。どちらも代替fsの合理的な選択です（ext4は非常に新しく、多くの人が問題なく使用していますが、まだ実稼働サーバーで信頼できるかどうかはわかりません）