:strip_icc():strip_exif()/u/105199/crop5cb76c6d18020_cropped.jpeg?f=community)
Hoi,
Ik heb momenteel forse bacula performance problemen die ik niet kan herleiden.
Geval:
Bacula-fd: een aantal VMs op een 100/100mbit colocated bak.
Dikke performance, goede IO snelheid.
Het is niet geniaal, maar voldoet.
Bacula-dir+sd:
Een atom bij mij thuis draait de director, met 120/10mbit (router op 100mbit...) internet.
Aan de atom (zelfde ethernetpoort, maar dat is gigabit) een netgear readynas via iscsi, met lvm+XFS.
hdparm schrijft daar redelijk lekker naar:
Deze performance is ook niet subliem maar het apparaat is momenteel ook al bezig diverse andere dingen, dus acceptabel genoeg.
Tijdens een backup loopt de load op beide machines ook niet erg op.
Mijn clients zijn vrij boring ingesteld op de director:
En de file-daemon:
Eveneens niet heel boeiend. De heartbeat intervals zijn nodig omdat de verbinding anders sneuvelt.
Tot deze week had mijn thuisbakje (de director) een ssd en haalde met dezelfde setup +- 1800kb/sec. Dit ongeacht of ik nou een full, incremental of differential backup draaide.
Nu heb ik de ssd vervangen door een disk met dezelfde config (en een reinstall gedaan) en ik zit op de helft daarvan.
Beide snelheden zijn imo (!) compleet onacceptabel; 20mbit is een lachertje.
Compressie kan ik aanzetten, maar ik wil het even zo eenvoudig mogelijk houden en dit zou een eventuele performance hit met zich mee kunnen brengen.
Uiteraard heb ik zelf wat onderzoek gedaan:
- io op de SD lijkt goed.
- io op de FD lijkt goed.
- bandbreedte tussen beide locaties is prima (ik kan strak met 100mbit downloaden vanaf de server naar huis).
- ik zie geen load-spikes (load wordt 0.6 ofzo) op de VMs.
- Downloaden vanaf/uploaden naar de VMs gaat ook prima met 100mbit. Xen en het netwerk zitten niet in de weg.
Een van de dingen die ik op internet veel teruglees zijn problemen met de tapes; tsja dat heb ik dus al niet. Ook de IO is momenteel prima in orde.
Paralleliseren van backups is vast een optie, maar laat ik momenteel eerst maar eens een backup een beetje soepel laten lopen.
Waar kan ik het beste gaan beginnen met kijken waar de bottleneck zit?
Een van de verdachten is mijn router, maar die zou het makkelijk aan moeten kunnen lijkt me; het is een Juniper netscreen 5GT. bittorrent/scp/usenet/streaming media: ik kan het er allemaal met 100mbit doorheen jagen, en dit is wel belachelijk slecht voor een 100mbit apparaat.
Ik heb momenteel forse bacula performance problemen die ik niet kan herleiden.
Geval:
Bacula-fd: een aantal VMs op een 100/100mbit colocated bak.
Dikke performance, goede IO snelheid.
code:
1
2
3
4
5
6
7
8
9
10
11
12
| root@www:/var# hdparm -t /dev/xvdb1 /dev/xvdb1: Timing buffered disk reads: 108 MB in 3.02 seconds = 35.75 MB/sec root@www:/var# hdparm -t /dev/xvdb1 /dev/xvdb1: Timing buffered disk reads: 132 MB in 3.02 seconds = 43.67 MB/sec root@www:/var# hdparm -t /dev/xvdb1 /dev/xvdb1: Timing buffered disk reads: 190 MB in 3.10 seconds = 61.34 MB/sec |
Het is niet geniaal, maar voldoet.
Bacula-dir+sd:
Een atom bij mij thuis draait de director, met 120/10mbit (router op 100mbit...) internet.
Aan de atom (zelfde ethernetpoort, maar dat is gigabit) een netgear readynas via iscsi, met lvm+XFS.
hdparm schrijft daar redelijk lekker naar:
code:
1
2
| /dev/mapper/san--vol-bacula: Timing buffered disk reads: 110 MB in 3.03 seconds = 36.28 MB/sec |
Deze performance is ook niet subliem maar het apparaat is momenteel ook al bezig diverse andere dingen, dus acceptabel genoeg.
Tijdens een backup loopt de load op beide machines ook niet erg op.
Mijn clients zijn vrij boring ingesteld op de director:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| JobDefs {
Name = "www-weekly"
Type = Backup
Level = Incremental
Client = www
FileSet = "Full Set"
Schedule = "WeeklyCycle"
Storage = leiden-filestorage
Messages = Standard
Pool = wwwPool
Priority = 10
}
Job {
Name = "wwwjob"
JobDefs = "www-weekly"
Write Bootstrap = "/var/lib/bacula/www.bsr"
}
Client {
Name = www
Address = www.foo.bar
FDPort = 9102
Catalog = MyCatalog
Password = "*" # password for FileDaemon
File Retention = 30 days # 30 days
Job Retention = 6 months # six months
AutoPrune = yes # Prune expired Jobs/Files
}
Pool {
Name = wwwPool
LabelFormat = "wwwVol"
Pool Type = Backup
Recycle = yes # Bacula can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 365 days # one year
Volume Use Duration = 23h
} |
En de file-daemon:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| Director {
Name = leiden-dir
Password = "*"
}
Director {
Name = www.foo.bar-mon
Password = "*"
Monitor = yes
}
FileDaemon { # this is me
Name = www.foo.bar-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
HeartBeat Interval = 15
Maximum Concurrent Jobs = 20
FDAddress = *
}
Messages {
Name = Standard
director = www.foo.bar-dir = all, !skipped, !restored
} |
Eveneens niet heel boeiend. De heartbeat intervals zijn nodig omdat de verbinding anders sneuvelt.
Tot deze week had mijn thuisbakje (de director) een ssd en haalde met dezelfde setup +- 1800kb/sec. Dit ongeacht of ik nou een full, incremental of differential backup draaide.
Nu heb ik de ssd vervangen door een disk met dezelfde config (en een reinstall gedaan) en ik zit op de helft daarvan.
Beide snelheden zijn imo (!) compleet onacceptabel; 20mbit is een lachertje.
Compressie kan ik aanzetten, maar ik wil het even zo eenvoudig mogelijk houden en dit zou een eventuele performance hit met zich mee kunnen brengen.
Uiteraard heb ik zelf wat onderzoek gedaan:
- io op de SD lijkt goed.
- io op de FD lijkt goed.
- bandbreedte tussen beide locaties is prima (ik kan strak met 100mbit downloaden vanaf de server naar huis).
- ik zie geen load-spikes (load wordt 0.6 ofzo) op de VMs.
- Downloaden vanaf/uploaden naar de VMs gaat ook prima met 100mbit. Xen en het netwerk zitten niet in de weg.
Een van de dingen die ik op internet veel teruglees zijn problemen met de tapes; tsja dat heb ik dus al niet. Ook de IO is momenteel prima in orde.
Paralleliseren van backups is vast een optie, maar laat ik momenteel eerst maar eens een backup een beetje soepel laten lopen.
Waar kan ik het beste gaan beginnen met kijken waar de bottleneck zit?
Een van de verdachten is mijn router, maar die zou het makkelijk aan moeten kunnen lijkt me; het is een Juniper netscreen 5GT. bittorrent/scp/usenet/streaming media: ik kan het er allemaal met 100mbit doorheen jagen, en dit is wel belachelijk slecht voor een 100mbit apparaat.
/u/125506/link-8bit.png?f=community)
voor de HDD. Dat verklaart dus het een en ander. SSDs ftw 
. Dat is dan natuurlijk helemaal niet leuk, twee schijven in korte tijd.
:strip_exif()/u/26026/snowrabb.gif?f=community)