On Tuesday, July 19, 2011 06:10:06 AM Dennis Benndorf did opine: > Hello Gene, > > thank you for your answere. Now our backup server is dumping with 100 > inparallel dumpers. > > One thing you have to explain a bit further to an non-native-speaking > person: "probably newer than your install as I play the part of the > geriatric (76 yo) canary in this here coal mine. ;-)"
Your English is much better than my German so we are far better doing this in English. Sorry. Chuckle, a "turn of the phrase". Since I live in WV, USA, and coal mining is a major industry here, I thought the comparison was appropriate. However I have never personally been in a coal mine. I've worked in electronics all my life, making a living at it since about '49, but now retired & making wood chips to keep me out of the bars. You can see some of that at <http://gene.homelinux.net:85/gene> which is actually this machine. Historically, coal miners took a canary in a cage into the mines with them, using the canaries singing as an air quality monitor. By running the (usually) most recent svn tarballs here, I am effectively testing the alpha code. Hence the remark about being the canary in the coal mine. If my install fails (the canary died), then the code isn't good. I ran Amanda version 4.0.0alpha.svn.4242 early this morning. It seemed to work well for my two clients. > How are we? Lets say that we are a public enterprise hosting some > servers for other plublic enterprises. How big is our amanda > installation? > > amanda@...:~$ amadmin daily hosts |wc -l > 100 > amanda@...:~$ amadmin daily dles |wc -l > 233 > > amanda@dl380-54:~$ amadmin daily balance > > due-date #fs orig MB out MB balance > ---------------------------------------------- > > 7/23 Sat 8 472004 165476 +2.0% > 7/24 Sun 2 137758 60193 -62.9% > > 7/30 Sat 8 472004 165476 +2.0% > 7/31 Sun 147 4358003 3126873 +1827.8% > 8/01 Mon 6 215482 163543 +0.8% > 8/02 Tue 6 235070 120318 -25.8% > 8/03 Wed 9 39854 25501 -84.3% > 8/04 Thu 1 212948 40739 -74.9% > 8/05 Fri 4 66 59 -100.0% > 8/06 Sat 8 472004 165476 +2.0% > 8/07 Sun 3 174102 91387 -43.7% > 8/08 Mon 17 191009 85464 -47.3% > 8/09 Tue 2 285718 91829 -43.4% > 8/10 Wed 1 165080 51475 -68.3% > 8/11 Thu 12 11078 5933 -96.3% > 8/12 Fri 3 3617 949 -99.4% > 8/13 Sat 8 472004 165476 +2.0% > 8/14 Sun 2 137758 60193 -62.9% > 8/15 Mon 2 3183 1468 -99.1% > 8/16 Tue 2 340170 92741 -42.8% > 8/17 Wed 12 221551 185296 +14.2% > ---------------------------------------------- > TOTAL 263 8620463 4865865 162195 > DISTINCT 233 6791177 4188858 > (estimated 30 runs per dumpcycle) > > I think it isnt quiet so big, but there will be more in the future. Why > did I want to increase this option? Because of some clients with lots > of data to get through in the nightly backup window. Before this, it > could happen that the bigger ones were dumped to late in the night. BTW > does anyone understand how the dumporder option really works; do I have > to set it for every dumper? In comparison to this the tapeorder option > is better to understand... I believe the 'dumporder' is global. Here I start with the big ones then the smaller so that amanda can use the little ones to facilitate filling the individual tape. There are no doubt nuances of this that could be better explained by Jean-Louis however. Very Handy if using real tapes, I am using vtapes here, so until the drive itself is full, there is no 'out of tape' condition except the size limit set in my amanda.conf. And this is regularly exceeded in actual use because I wrap amanda in some scripts that add its database to the vtape after amanda has finished its nightly run. By that means, my backup database is a day newer in the event I am forced to do a bare metal recovery on a new drive. This does however, add about 200Mb to each vtape, including a tarball of all of amanda's config. One of the controls in the dle list is the spindle number, and this should be enumerated (I think) such that each drive at an _individual_ clients site has its own unique number starting with 0,1,2 etc. By this means, amanda is prevented from asking that client for 2 or more simultaneous dumper sessions on the same drive, which would cause the dumper sessions to fight with each other, each one issuing excessive seeks and hammering the drives seek machinery, wasting time in the overall operation that would not be wasted if amanda waited for that one to finish before starting the dump of another dle whose partition or directory tree is on the same drive. I hope this helps. We I think are always glad to hear of amanda being used in the enterprise. As the business grows, refresh the list please with an occasional bragging email. ;-) > Regards, > Dennis > > > > > > > -------- Original-Nachricht -------- > > > Datum: Tue, 12 Jul 2011 10:17:08 -0400 > > Von: gene heskett <[email protected]> > > An: "Dennis Benndorf" <[email protected]>, > > [email protected] Betreff: Re: Increase MAX_DUMPERS in > > "inparallel" option > > > > On Tuesday, July 12, 2011 09:43:54 AM Dennis Benndorf did opine: > > > Hello Gene, > > > > > > thanx for your response. Lets see how many dumpers are there tonight > > > ;-) > > > > > > Regards, > > > Dennis > > > > > > > > > > > > -------- Original-Nachricht -------- > > > > > > > Datum: Tue, 12 Jul 2011 09:10:15 -0400 > > > > Von: gene heskett <[email protected]> > > > > An: [email protected] > > > > Betreff: Re: Increase MAX_DUMPERS in "inparallel" option > > > > > > > > On Tuesday, July 12, 2011 09:09:10 AM Dennis Benndorf did opine: > > > > > Hello @all, > > > > > > > > > > I want to increase the maximum of inparallel dumps, but dont > > > > > know really how. I looked in the source of > > > > > server-src/driverio.h but there is no value to set higher. > > > > > > > > > > -------- > > > > > > > > > > inparallel 63 # maximum dumpers that will run in > > > > > parallel (max 63) # this maximum can be increased at > > > > > compile-time, # modifying MAX_DUMPERS in server-src/driverio.h > > > > > -------- > > > > > > > > > > Wouldnt this be nice to have this configured with ./configure > > > > > MAX_DUMPERS=100 or so? > > > > > > > > > > Regards, > > > > > Dennis > > > > > > > > It looks like its been moved, to "common-src/amanda.h" > > > > > > > > Cheers, gene > > > > Word wrap off, long lines from grep ahead. > > > > Its great that you found it. This is a case of grep -R being your > > friend. > > > > Example: > > [root@coyote amanda-4.0.0alpha.svn.4221]# grep -R MAX_DUMPERS * > > Binary file common-src/.libs/libamanda-4.0.0alpha.svn.4221.so matches > > Binary file common-src/.libs/conffile.o matches > > Binary file common-src/.libs/libamanda.a matches > > Binary file common-src/.libs/libamanda.so matches > > common-src/amanda.h:#define MAX_DUMPERS 63 <-------target of search, > > gives the value. The rest of this is just usage. > > common-src/conffile.c: if(val_t__int(val) < 1 || val_t__int(val) > > > > >MAX_DUMPERS) > > > > common-src/conffile.c: conf_parserror(_("inparallel must be between 1 > > and MAX_DUMPERS (%d)"), > > common-src/conffile.c: MAX_DUMPERS); > > Binary file common-src/conffile.o matches > > example/template.d/advanced.conf: # modifying > > MAX_DUMPERS in server-src/driverio.h > > example/template.d/advanced.conf.in: # modifying > > MAX_DUMPERS in server-src/driverio.h > > example/amanda.conf: # modifying MAX_DUMPERS in > > server-src/driverio.h > > example/amanda.conf.in: # modifying MAX_DUMPERS in > > server-src/driverio.h > > server-src/driverio.c: for(dumper = dmptable; dumper < dmptable + > > MAX_DUMPERS; dumper++) { > > server-src/driverio.c: for (dumper = dmptable; dumper < dmptable + > > MAX_DUMPERS; dumper++) { > > server-src/driverio.c:#define MAX_SERIAL MAX_DUMPERS*2 /* one for > > each dumper and taper */ > > server-src/driver.c: if(inparallel > MAX_DUMPERS) inparallel = > > MAX_DUMPERS; > > server-src/driverio.h:GLOBAL dumper_t dmptable[MAX_DUMPERS]; > > server-src/driverio.h:GLOBAL chunker_t chktable[MAX_DUMPERS]; > > --------end of grep output---------- > > > > From that it appears the message in amanda.conf needs to be updated > > also. Also please note that I did that grep search in > > amanda-4.0.0alpha.svn.4221, > > probably newer than your install as I play the part of the geriatric > > (76 yo) > > canary in this here coal mine. ;-) > > > > I have no clue when it may actually have been moved from where > > amanda.conf says it is. The ChangeLog for amanda-4.0.0alpha.svn.4221 > > starts Jan 11, 2008, and this change is not mentioned in a form grep > > can find. > > > > You I take it, must have a large system with a 64 spindles or more > > if you need to expand that value from the usual one dumper per > > spindle. Would you care to identify it further? We are always > > interested in finding > > out who the big users of amanda are. > > > > However, replies to a mailing list message should always go back to > > the mailing list to constitute a record of the question being > > answered for the next person who might ask that question. The list > > archive is searchable, doing so is common courtesy, and is expected, > > so I have added the list to my reply. You, Dennis, will probably get > > 2 copies. > > > > Cheers, gene Cheers, gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The decision doesn't have to be logical; it was unanimous.
