web-dev-qa-db-ja.com

バキュラのバックアップは非常に遅く、TCPソケットは 'unkn-4'状態です

複数のbacula-fdクライアントが1つのbaculaSDをバックアップしています（テープではなく、大規模なRAID上の2Gディスクファイルを使用）。通常は2〜3個を同時にバックアップします。 2つの大きなクライアント（それぞれ約400〜900 GB）が完全バックアップを実行する必要がある場合を除いて、正常に機能します。これは非常に遅くなり（通常、約200〜2500 Kバイト/秒）、完全バックアップは数日で完了しません。私たちにとって問題です（それで私たちはそれをキャンセルしてインクリメンタルで行きます）。

サーバーとクライアントは異なるVLAN /サブネットにあるため、VLANといくつかのスイッチを備えた別のDebianwheezyマシンを介してルーティングされます。 NICは、スイッチと同様に、すべてのマシンで1Gbpsです（アクティブ-パッシブネットワークボンディングを備えたマシン-フェイルオーバーしても速度は向上しません）。マシンはクアッドと8コアで、8〜64 GBのRAMを搭載し、スワップに移行せず、負荷は0.2〜2であるため、CPU、I/O、メモリ不足ではないと思います。 Bacula-sdは、負荷がかかっていないように見えるハードウェアRAIDにもあります。また、ネットワークはその時点ではほとんどアイドル状態であるため、帯域幅の輻輳であってはなりません。 Baculaバージョンは標準のwheezy5.2.6 + dfsg-9であり、Linuxカーネルも標準のwheezy 3.2.60-1 + deb7u3です。

転送は問題なく開始されるようです（約20メガバイト/秒で、これは多くの小さなファイルで予想されます）。ある瞬間にSend-Qが上昇し、数十秒（または数分）下降しないよりも、およびnetstatは、「unkn-4」タイマーにソケットを表示し、指数関数的に増加するタイムアウトで再起動します。

# netstat -tpno   | grep bacula
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name Timer
tcp        0 967688 10.66.3.135:49668   10.66.2.11:9103         ESTABLISHED 2964/bacula-fd   unkn-4 (1.86/0/0)
tcp        0      0 10.66.3.135:9102    10.66.2.11:54499        ESTABLISHED 2964/bacula-fd   keepalive (5882.64/0/0)

その後、しばらくすると、パケットが再び開始されたように見えます。

# netstat -tpno    | grep bacula
tcp        0  38054 10.66.3.135:49668   10.66.2.11:9103         ESTABLISHED 2964/bacula-fd   on (0.21/0/0)
tcp        0      0 10.66.3.135:9102    10.66.2.11:54499        ESTABLISHED 2964/bacula-fd   keepalive (385.49/0/0)

バックアップは続行されます（bconsoleのstatus client=blowgun-fdで確認）。例えば：

* status client=axe-fd
newaxe-fd Version: 5.2.6 (21 February 2012)  x86_64-pc-linux-gnu debian 7.0
Daemon started 24-Oct-14 17:27. Jobs: run=0 running=0.
 Heap: heap=683,600 smbytes=761,617 max_bytes=807,280 bufs=396 max_bufs=426
 Sizeof: boffset_t=8 size_t=8 debug=200 trace=1 
Running Jobs:
JobId 12640 Job axe.2014-10-24_23.05.01_40 is running.
    Full Backup Job started: 24-Oct-14 23:05
    Files=2,529,050 Bytes=253,018,715,824 Bytes/sec=1,479,901 Errors=6
    Files Examined=2,529,050
    Processing file: /home/users/novoselo/public_html/~2511/templates/js_corp/images/bg.jpg
    SDReadSeqNo=5 fd=5
Director connected at: 26-Oct-14 21:34

bg.jpgのサイズは1.2MBで、数分間そのままでした...

ディレクター、SD、およびファイルデーモンの構成では、ハービート間隔が120に設定されており、正常に機能しているようです。 setdebug level=200 trace=1 allを使用してデバッグトレースファイルを有効にすると、次のようになります。

newaxe-fd: backup.c:371-0 FT_REG saving: /home/users/novoselo/public_html/~2511/templates/js_corp/images/bg.jpg
newaxe-fd: backup.c:469-0 bfiled: sending /home/users/novoselo/public_html/~2511/templates/js_corp/images/bg.jpg to stored
newaxe-fd: crypto.c:607-0 crypto_digest_new jcr=2f01748
newaxe-fd: backup.c:1467-0 No strip for /home/users/novoselo/public_html/~2511/templates/js_corp/images/bg.jpg
newaxe-fd: backup.c:609-0 type=3 do_read=1
newaxe-fd: bfile.c:963-0 open file /home/users/novoselo/public_html/~2511/templates/js_corp/images/bg.jpg
newaxe-fd: backup.c:1194-0 Send data to SD len=65135
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: backup.c:1194-0 Send data to SD len=65562
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0
newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0

straceは次のことを確認しているようです：

# strace -tt -ff -s999 -p 3907
Process 3907 attached with 4 threads - interrupt to quit
[pid 27650] 22:25:15.705796 write(5, "[....]"..., 55110 <unfinished ...>
[pid 27661] 22:25:15.706103 select(6, [5], NULL, NULL, {2, 804806} <unfinished ...>
[pid  3912] 22:25:15.706147 restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid  3907] 22:25:15.706168 select(4, [3], NULL, NULL, NULL <unfinished ...>
[pid  3912] 22:25:16.619938 <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid  3912] 22:25:16.620008 futex(0x397d82d0240, FUTEX_WAKE_PRIVATE, 1) = 0
[pid  3912] 22:25:16.620092 futex(0x397d82d0284, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13229, {1414358746, 620076000}, ffffffff <unfinished ...>
[pid 27661] 22:25:18.513819 <... select resumed> ) = 0 (Timeout)
[pid 27661] 22:25:18.513858 write(15, "newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0\n", 47) = 47
[pid 27661] 22:25:18.513928 select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
[pid 27661] 22:25:23.519025 write(15, "newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0\n", 47) = 47
[pid 27661] 22:25:23.519139 select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
[pid 27661] 22:25:28.524240 write(15, "newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0\n", 47) = 47
[pid 27661] 22:25:28.524317 select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
[pid 27661] 22:25:33.529409 write(15, "newaxe-fd: heartbeat.c:96-0 wait_intr=0 stop=0\n", 47) = 47
[pid 27661] 22:25:33.529508 select(6, [5], NULL, NULL, {5, 0}^C <unfinished ...>

fd 5はbacula-sdへのネットワーク接続であり、書き込み時にプロセスがブロックされています。調査中 nkn-4 は、実際には「ゼロウィンドウプローブタイマーが保留中」であることを示しているようです。

ですから、何らかの理由で（バグ？）または（おそらく私見）何らかのネットワークの問題でスロットルを実行しているのは、bacula-sdのように見えます。

アクティブなイーサネットアダプタにエラーがあるようには見えません。 ethtoolを使用してオフロードやその他の機能を無効にしようとしましたが、役に立ちませんでした。 ping -fは、TCPの問題が顕在化している場合でも、パケットを失うことはありません。

axe# ping -s1400 -f -c1000 10.66.2.11
--- slingshot.tomsoft.lan ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 607ms
rtt min/avg/max/mdev = 0.391/0.582/0.672/0.039 ms, ipg/ewma 0.608/0.585 ms

これをトラブルシューティングする（そしてもちろん最終的に修正する）方法のアイデアを探していますか？

UPDATE1： 調整TCP buffers 状況はこれ以上良くない-ただキューは大きくなりますが、それでもブロックされ、バックアップはまだ遅いです。wiresharkダンプをもう少し調べたところ、bacula-sdソフトウェアの問題のようで、TCP ZeroWindowは通常のカーネルの方法です。スロットルTCPその場合。したがって、マシンはデータを受信して​​いるように見えますが、マシンに負荷がかかっていないにもかかわらず、bacula-sdはデータを十分に高速に処理できないようです。これはオンです。 bacula-sd側：

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name Timer
tcp   3952353      0 10.66.2.11:9103         10.66.3.132:45226   ESTABLISHED 15839/bacula-sd  keepalive (4863.09/0/0)
# uptime
 05:23:13 up 2 days, 14:40,  2 users,  load average: 0.42, 0.32, 0.27
linux-networkingdebian-wheezybaculaslow-connection
2
Matija Nalis

それはSQLでした。

デフォルトでは、bacula-fdが新しいファイルを送信するたびに、bacula-sdは（bacula-dirを介して）ファイル属性をSQL batchテーブルに挿入しようとします。小さなファイルがたくさんあり、SQLが非常に高速でない場合は、わずかな遅延が挿入されます。多くの小さな遅延=速度の抑制= Max Run Sched Timeを超えたためにバックアップがキャンセルされました。また、アーキテクチャにより、複数のバックアップを実行している場合でも、すべてが遅くなります。

解決策（種類）は次を追加することでした：

Spool Data = no
Spool Attributes = yes

JobDefs {...}のbacula-dir.confセクションにあります（テープストレージではなくディスクストレージであるため、Spool Data = noを使用していることに注意してください。オーバーヘッドが増えるだけです）。 Spool Attributes = yesを使用すると、baculaはファイル属性をファイルに書き込み、ジョブが終了したときにのみファイルがSQLサーバーに送信されます。 bacula-fdへの接続は、データ転送が完了するとすぐに解放される（そしてクライアントのディスク/ネットワークの負荷が終了する）ことに注意してください（したがって、SQLの挿入が完了するのを待ちません）。

いくつかの注意：

  • 「SQLは非常に高速ではありません」とは、1秒あたりわずか数十のクエリしか実行しないことを意味します。
  • 私の場合、問題のあるサーバーには約300万のファイルと350GBのディスク容量がありました。 4日で完全バックアップを完了できず、転送速度が200Kバイト/秒に低下しました。
  • 属性スプーリングを使用すると、2日と13時間で終了します。一目でそれほど大きな改善はありませんが（元のバックアップは完了しなかったので、多分そうかもしれません）、データ転送自体は4.5時間、平均速度は約18メガバイト/秒です。 （これは、サーバーが他のことを行う一方で、多くの小さなファイルや圧縮にはそれほど悪くありません）。ただし、ローカルファイルからSQLサーバーへの属性のデスプールには次の時間がかかります56.5時間！ 2日以上!!
  • 問題のSQLサーバーは、8コアI7 @ 3.70GHz、64GB RAM、4ディスクRAID-10の専用MySQL（5.5.40-0 + wheezy1）です。他のことも行い、binlogが有効になっていますが、バックアップの実行中はほとんどアイドル状態です。それは他の負荷に対しては非常にうまく機能し、innodb_buffer_pool_sizeはbaculaのすべてのインデックスよりも大きいです。それあるべき正常に動作しています。
  • 属性スプーリングが有効になっている場合でも、baculaはバッチ挿入（またはLOAD DATA LOCAL INFILE）を使用しないようですが、300万の挿入を1つずつ送信し、それぞれの確認を待ちます（属性データは約1GBのコンパクトなバイナリファイルに保存されます）大きい。ASCII SQL INSERTステートメントに変換されると、確実にその2倍になります）。したがって、MySQLが他のマシン上にあるために待ち時間が長くなると、パフォーマンスが完全に低下するようです。
  • SQLが遅い理由を詳しく調べてみますが、最善の解決策はMySQLを（パフォーマンスがはるかに低い）ローカルマシンに配置することだと思います。おそらく、私がそれに取り組んでいる間、それを優先PostgreSQLに置き換えます。

Edit1：baculaを（手動で作成されたパッケージ）5.2.13にアップグレードしますdoesバッチ挿入のサポートが含まれます（Debian wheezy/jessieでパッケージ化された5.2.6の代わりにしない）、そして一時テーブルがtmpfsに作成されるようにMySQLデータベースを調整することで、前述の属性のデスプール時間を56.5時間から30分に短縮しました。ローカルマシン（bacula-sdとbacula-dirと同じ）でPostgreSQLに置き換えると、おそらくそれでも改善されると思いますが、これで十分です。

2
Matija Nalis