2GB limit

[Maritza Mendez]

On Sat, Oct 9, 2010 at 6:47 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/9/2010 12:24 AM, Maritza Mendez wrote:
> > I think I have a solid way to reproduce the VM issue, without resorting
> > to ulimit.  (I'm concerned that ulimit may cause a non-problem to become
> > a problem and so mask the actual problem.)
> >
> > Can someone confirm whether the trace attached is a definitive signature
> > of the VM limit recently known as the 2GB limit?  I want to make sure
> > I'm looking at the right problem!
> >
> > Thanks!
> > ~M
> >
> >
>
> 84.753  Adding the key (<bzrlib.btree_index.BTreeGraphIndex object at
> 0x02F73030>, 110895463, 93519167) to an LRUSizeCache failed. value
> 418921803 is too big to fit in a the cache with size 41943040 52428800
>
> ^- this looks like you are dealing with some very large content objects
> (419MB for a single blob.)
>
>
> ...
>
>  File "bzrlib\groupcompress.pyo", line 538, in _prepare_for_extract
>  File "bzrlib\groupcompress.pyo", line 151, in _ensure_content
> MemoryError
>
> And this does look like it is failing during the zlib.decompress stage.
>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkywcmYACgkQJdeBCYSNAAMwwwCg2bWv9WSBju80HG5Z+K4g2nwR
> BeEAoIAsexMDPH1h0kV81UzGTMzYe5zl
> =CyUE
> -----END PGP SIGNATURE-----
>


Strange...  I need to track down that object of course.

Can we tell from the log (which was on the Win7x64 machine trying to pull
from a newly created branch on an Ubuntu box) whether the problem occurred
in 'bzr checkout' on the Win7x64 box as the log might suggest or whether the
actual problem occurred in the 'bzr serve' on the Ubuntu box?  I ask this
because the Linux box is deliberately penalized [1] with only 512MB or RAM
and the WIn7x64 box has 2GB.

[1] I expect to have repos which are large compared to physical RAM.  So to
accelerate testing it turns out to be convenient to work with modest (1.5
GB) branches on a low-memory system.  For example, back in the bzr 2.0 days,
bzr just could not finish committing teh origional branch on the 512MB
Ububtu box.  Now, with bzr 2.2, bzr survives an hour or more of
disk-thrashing and gets the branch committed.  Yes, I am sometimes cruel.
We like stress testing, because we know the future will be stressful.

~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20101009/554ce9c8/attachment-0001.htm