Bacula-users

Re: [Bacula-users] Performance with latent networks

2011-10-03 04:39:26
Subject: Re: [Bacula-users] Performance with latent networks
From: mayak-cq <mayak AT australsat DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Mon, 03 Oct 2011 10:34:52 +0200
On Sun, 2011-10-02 at 11:45 +0200, Radosław Korzeniewski wrote:
Hello,

2011/9/30 reaper <bacula-forum AT backupcentral DOT com>
sounds like your sysctl.conf needs tweaking? have you tried something like this on both sides?

 kernel.msgmnb = 65536
 kernel.msgmax = 65536
 kernel.shmmax = 68719476736
 kernel.shmall = 4294967296


These are the IPC (inter process communication) kernel parameters and have nothing about network tuning and AFAIK Bacula doesn't use IPC. I'm not suprised that there was no effect. :)

hi radoslaw, hi reaper,

yes -- i have just sniffed to some traffic and done a backup over 100mbit network -- here are the results

zurich running bacula-dir and bacula-sd (backup server)
copenhagen running bacula-fd (backup client)

heres the 3 way handshake (bolding is mine)

No.     Time        Source                Destination           Protocol Info
      1 0.000000    zurich         copenhagen        TCP      33252 > bacula-fd [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=2129448587 TSER=0 WS=6

Frame 1: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
Linux cooked capture
Internet Protocol, Src: zurich (zurich), Dst: copenhagen (copenhagen)
Transmission Control Protocol, Src Port: 33252 (33252), Dst Port: bacula-fd (9102), Seq: 0, Len: 0
    Source port: 33252 (33252)
    Destination port: bacula-fd (9102)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
    Window size: 5840
    Checksum: 0xa51b [validation disabled]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        TCP SACK Permitted Option: True
        Timestamps: TSval 2129448587, TSecr 0
        NOP
        Window scale: 6 (multiply by 64)

No.     Time        Source                Destination           Protocol Info
      2 0.000036    copenhagen        zurich         TCP      bacula-fd > 33252 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSV=1494684643 TSER=2129448587 WS=8

Frame 2: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
Linux cooked capture
Internet Protocol, Src: copenhagen (copenhagen), Dst: zurich (zurich)
Transmission Control Protocol, Src Port: bacula-fd (9102), Dst Port: 33252 (33252), Seq: 0, Ack: 1, Len: 0
    Source port: bacula-fd (9102)
    Destination port: 33252 (33252)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 40 bytes
    Flags: 0x12 (SYN, ACK)
    Window size: 5792
    Checksum: 0xa123 [validation disabled]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        TCP SACK Permitted Option: True
        Timestamps: TSval 1494684643, TSecr 2129448587
        NOP
        Window scale: 8 (multiply by 256)
    [SEQ/ACK analysis]

No.     Time        Source                Destination           Protocol Info
      3 0.023054    zurich         copenhagen        TCP      33252 > bacula-fd [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=2129448610 TSER=1494684643

Frame 3: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Linux cooked capture
Internet Protocol, Src: zurich (zurich), Dst: copenhagen (copenhagen)
Transmission Control Protocol, Src Port: 33252 (33252), Dst Port: bacula-fd (9102), Seq: 1, Ack: 1, Len: 0
    Source port: 33252 (33252)
    Destination port: bacula-fd (9102)
    [Stream index: 0]
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 5888 (scaled)
    Checksum: 0xe61d [validation disabled]
    Options: (12 bytes)
        NOP
        NOP
        Timestamps: TSval 2129448610, TSecr 1494684643
    [SEQ/ACK analysis]



zurich and copenhagen are 22.589 ms apart on a shared 100mbit connection -- using the bandwidth delay product:

theoretical
bandwidth       delay        productBits         bitsPerByte      bytesInWindow
500 000 000 * .022589 = 11 294 50             /   8                =  1 411 813

actual
windowSizeBytes      windowScale      bytesInWindow                                                        delay            throughputBytesPerSecond               bitsPerSecond   
5840                        *  64                   =    373 760                    zurich -> copenhagen      / .022589          16 546 107                              * 8         132 368 856
5888                        *  256                 = 1 507 328                    copenhagen -> zurich      / .022589          66 728 408                              * 8         533 827 264



i backed up about 16GB of data uncompressed from copenhagen to zurich at around 60mbits/s.



i am lost as far as bacula's window calculation -- it thinks that i have a 500mbit connection?


cheers

m




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
<Prev in Thread] Current Thread [Next in Thread>