bup-memtest(1)						      General Commands Manual						    bup-memtest(1)

NAME

       bup-memtest - test bup memory usage statistics

SYNOPSIS

       bup memtest [options...]

DESCRIPTION

       bup memtest  opens  the	list  of pack indexes in your bup repository, then searches the list for a series of nonexistent objects, printing
       memory usage statistics after each cycle.

       Because of the way Unix systems work, the output will usually show a large (and unchanging) value in the VmSize column, because mapping the
       index files in the first place takes a certain amount of virtual address space.	However, this virtual memory usage is entirely virtual; it
       doesn't take any of your RAM.  Over time, bup uses parts of the indexes, which need to be loaded from disk, and	this  is  what	causes	an
       increase in the VmRSS column.

OPTIONS

       -n, --number=number
	      set the number of objects to search for during each cycle (ie.  before printing a line of output)

       -c, --cycles=cycles
	      set the number of cycles (ie.  the number of lines of output after the first).  The first line of output is always 0 (ie.  the base-
	      line before searching for any objects).

       --ignore-midx
	      ignore any .midx files created by bup midx.  This allows you to compare memory performance with and without using midx.

       --existing
	      search for existing objects instead of searching for random nonexistent ones.  This can greatly affect memory usage and performance.
	      Note  that most of the time, bup save spends most of its time searching for nonexistent objects, since existing ones are probably in
	      unmodified files that we won't be trying to back up anyway.  So the default behaviour reflects real bup performance more accurately.
	      But you might want this option anyway just to make sure you haven't made searching for existing objects much worse than before.

EXAMPLE

	      $ bup memtest -n300 -c5
	      PackIdxList: using 1 index.
			     VmSize	 VmRSS	   VmData      VmStk
		      0    20824 kB    4528 kB	  1980 kB      84 kB
		    300    20828 kB    5828 kB	  1984 kB      84 kB
		    600    20828 kB    6844 kB	  1984 kB      84 kB
		    900    20828 kB    7836 kB	  1984 kB      84 kB
		   1200    20828 kB    8736 kB	  1984 kB      84 kB
		   1500    20828 kB    9452 kB	  1984 kB      84 kB

	      $ bup memtest -n300 -c5 --ignore-midx
	      PackIdxList: using 361 indexes.
			     VmSize	 VmRSS	   VmData      VmStk
		      0    27444 kB    6552 kB	  2516 kB      84 kB
		    300    27448 kB   15832 kB	  2520 kB      84 kB
		    600    27448 kB   17220 kB	  2520 kB      84 kB
		    900    27448 kB   18012 kB	  2520 kB      84 kB
		   1200    27448 kB   18388 kB	  2520 kB      84 kB
		   1500    27448 kB   18556 kB	  2520 kB      84 kB

DISCUSSION

       When optimizing bup indexing, the first goal is to keep the VmRSS reasonably low.  However, it might eventually be necessary to swap in all
       the indexes, simply because you're searching for a lot of objects, and this will cause your RSS to grow as large as VmSize eventually.

       The key word here is eventually.  As long as VmRSS grows reasonably slowly, the amount of disk activity caused by accessing pack indexes is
       reasonably  small.  If it grows quickly, bup will probably spend most of its time swapping index data from disk instead of actually running
       your backup, so backups will run very slowly.

       The purpose of bup memtest is to give you an idea of how fast your memory usage is growing, and to help in optimizing bup for better memory
       use.  If you have memory problems you might be asked to send the output of bup memtest to help diagnose the problems.

       Tip: try using bup midx -a or bup midx -f to see if it helps reduce your memory usage.

       Trivia:	index  memory  usage  in  bup  (or git) is only really a problem when adding a large number of previously unseen objects.  This is
       because for each object, we need to absolutely confirm that it isn't already in the database, which requires us to search through  all  the
       existing  pack  indexes to ensure that none of them contain the object in question.  In the more obvious case of searching for objects that
       do exist, the objects being searched for are typically related in some way, which means they probably all exist in a small number of  pack-
       files, so memory usage will be constrained to just those packfile indexes.

       Since  git  users  typically  don't add a lot of files in a single run, git doesn't really need a program like bup midx.  bup, on the other
       hand, spends most of its time backing up files it hasn't seen before, so its memory usage patterns are different.

SEE ALSO

       bup-midx(1)

BUP

       Part of the bup(1) suite.

AUTHORS

       Avery Pennarun <apenwarr@gmail.com>.

Bup unknown-															    bup-memtest(1)