librelist archives

« back to archive

[ANNOUNCE] Attic 0.14 Released

[ANNOUNCE] Attic 0.14 Released

From:
Jonas Borgström
Date:
2014-12-17 @ 22:59
Hello list,

After a fairly long delay I'm very happy to finally announce the Attic 
0.14 release. This release contains
a fair amount of bug fixes and improvements since the last release:

- Added support for stripping leading path segments (#95)
  "attic extract --strip-segments X"
- Add workaround for old Linux systems without acl_extended_file_no_follow (#96)
- Add MacPorts' path to the default openssl search path (#101)
- HashIndex improvements, eliminates unnecessary IO on low memory systems.
- Fix "Number of files" output for attic info. (#124)
- limit create file permissions so files aren't read while restoring
- Fix issue with empty xattr values (#106)

https://attic-backup.org/

/ Jonas

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Thiago Coutinho
Date:
2014-12-18 @ 10:37
Thanks!

2014-12-17 20:59 GMT-02:00 Jonas Borgström <jonas@borgstrom.se>:
>
> Hello list,
>
> After a fairly long delay I'm very happy to finally announce the Attic
> 0.14 release. This release contains
> a fair amount of bug fixes and improvements since the last release:
>
> - Added support for stripping leading path segments (#95)
>   "attic extract --strip-segments X"
> - Add workaround for old Linux systems without acl_extended_file_no_follow
> (#96)
> - Add MacPorts' path to the default openssl search path (#101)
> - HashIndex improvements, eliminates unnecessary IO on low memory systems.
> - Fix "Number of files" output for attic info. (#124)
> - limit create file permissions so files aren't read while restoring
> - Fix issue with empty xattr values (#106)
>
> https://attic-backup.org/
>
> / Jonas
>
>
>

-- 
Thiago Coutinho

"O povo não deveria temer o governo. O governo é quem deveria temer o povo."
V de Vingança

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Alberto Luaces
Date:
2014-12-19 @ 23:16
Hi,

on my linux system, 0.14 starts gathering memory until it is stopped by
the OOM killer (it has 2Gb of RAM and no swap space).

Should I check for anything in particular or start bisecting between
0.13 and 0.14?

Thanks,

--
Alberto

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Dmitry Astapov
Date:
2014-12-21 @ 15:24
I could confirm that something looks odd after upgrading to 0.14. I have a
particular archive that attic is still able to back up to, however, if I
try to "list" it, I see that attic is rapidly allocating tons of memory
until it is killed after allocating about 4Gb of VSS.

Box has 1Gb of physical RAM and 2Gb of swap.

Log from the latest backup (so that you could see total size, number of
files, etc):
Archive name: 2014-12-21_02.00
Archive fingerprint:
309ff6ec914f7db90012ef4c55d92fe7610447e9b73af56036ff0d320fb50ea5
Start time: Sun Dec 21 02:00:06 2014
End time: Sun Dec 21 02:20:05 2014
Duration: 19 minutes 59.54 seconds
Number of files: 99813

                       Original size      Compressed size    Deduplicated
size
This archive:               40.60 GB             34.61 GB             95.10
MB
All archives:                7.20 TB              5.96 TB            128.22
GB


Error:

Traceback (most recent call last):
  File "/usr/local/bin/attic", line 3, in <module>
    main()
  File "/usr/local/lib/python3.3/dist-packages/attic/archiver.py", line
727, in main
    exit_code = archiver.run(sys.argv[1:])
  File "/usr/local/lib/python3.3/dist-packages/attic/archiver.py", line
717, in run
    return args.func(args)
  File "/usr/local/lib/python3.3/dist-packages/attic/archiver.py", line
297, in do_list
    for archive in sorted(Archive.list_archives(repository, key, manifest),
key=attrgetter('ts')):
  File "/usr/local/lib/python3.3/dist-packages/attic/archive.py", line 415,
in list_archives
    yield Archive(repository, key, manifest, name, cache=cache)
  File "/usr/local/lib/python3.3/dist-packages/attic/archive.py", line 128,
in __init__
    self.items_buffer = CacheChunkBuffer(self.cache, self.key, self.stats)
  File "/usr/local/lib/python3.3/dist-packages/attic/archive.py", line 99,
in __init__
    super(CacheChunkBuffer, self).__init__(key)
  File "/usr/local/lib/python3.3/dist-packages/attic/archive.py", line 65,
in __init__
    self.packer = msgpack.Packer(unicode_errors='surrogateescape')
  File "_packer.pyx", line 73, in msgpack._packer.Packer.__cinit__
(msgpack/_packer.cpp:73)
MemoryError: Unable to allocate internal buffer.


As always, I am happy to provide more info, try out patches, etc.

On Fri, Dec 19, 2014 at 11:16 PM, Alberto Luaces <aluaces@udc.es> wrote:

> Hi,
>
> on my linux system, 0.14 starts gathering memory until it is stopped by
> the OOM killer (it has 2Gb of RAM and no swap space).
>
> Should I check for anything in particular or start bisecting between
> 0.13 and 0.14?
>
> Thanks,
>
> --
> Alberto
>



-- 
Dmitry Astapov

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Jonas Borgström
Date:
2015-01-03 @ 21:47
On 2014-12-21 16:24, Dmitry Astapov wrote:
> I could confirm that something looks odd after upgrading to 0.14. I
> have a particular archive that attic is still able to back up to,
> however, if I try to "list" it, I see that attic is rapidly allocating
> tons of memory until it is killed after allocating about 4Gb of VSS.
>
> Box has 1Gb of physical RAM and 2Gb of swap.

The obvious culprit in the 0.14 release is this change:
HashIndex: Switch to a non-mmap based implementation:
https://github.com/jborg/attic/commit/2f72b9f96001310ca4a81f8336545f2a3dd1de04

Before this change Attic did not actually load the hash index files into
memory but instead used mmap to access and update them.
The benefit with that approach was that the files didn't actually need
to fit into memory for this to work (but the performance would be very
poor if they don't).
But as some of you noticed the downside with this approach was that the
OS could in some cases perform a lot more write operations than needed,
especially if the system was low on ram.
You could say the mmap() usage was a way for Attic to "swap" without
using any swap space.

The 0.14 approach is a more traditional malloc() based approach which
should have a much more predictable behavior, and generally perform
slightly better. But only as long as the system has enough free ram (or
swap space) to contain the index data.

Are you able to add more swap space to your system? i think given enough
swap space Attic 0.14 should perform as good, or better than 0.13.

/ Jonas

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Dmitry Astapov
Date:
2015-01-03 @ 22:24
I actually believe that something else is a root cause: see
https://github.com/jborg/attic/issues/163 for detailed description and
possible fix.

As for the files not fitting in memory, hash index in question is 700 Mb,
there is 1Gb ram(mostly unused), and when "attic created" runs I see that
attic allocates 1.4Gb (does it always use twice the hash index size?) and
swaps a bit, though it does not bother me much.

On Sat, Jan 3, 2015 at 9:47 PM, Jonas Borgström <jonas@borgstrom.se> wrote:

>
> On 2014-12-21 16:24, Dmitry Astapov wrote:
> > I could confirm that something looks odd after upgrading to 0.14. I
> > have a particular archive that attic is still able to back up to,
> > however, if I try to "list" it, I see that attic is rapidly allocating
> > tons of memory until it is killed after allocating about 4Gb of VSS.
> >
> > Box has 1Gb of physical RAM and 2Gb of swap.
>
> The obvious culprit in the 0.14 release is this change:
> HashIndex: Switch to a non-mmap based implementation:
>
> https://github.com/jborg/attic/commit/2f72b9f96001310ca4a81f8336545f2a3dd1de04
>
> Before this change Attic did not actually load the hash index files into
> memory but instead used mmap to access and update them.
> The benefit with that approach was that the files didn't actually need
> to fit into memory for this to work (but the performance would be very
> poor if they don't).
> But as some of you noticed the downside with this approach was that the
> OS could in some cases perform a lot more write operations than needed,
> especially if the system was low on ram.
> You could say the mmap() usage was a way for Attic to "swap" without
> using any swap space.
>
> The 0.14 approach is a more traditional malloc() based approach which
> should have a much more predictable behavior, and generally perform
> slightly better. But only as long as the system has enough free ram (or
> swap space) to contain the index data.
>
> Are you able to add more swap space to your system? i think given enough
> swap space Attic 0.14 should perform as good, or better than 0.13.
>
> / Jonas
>
>
>


-- 
Dmitry Astapov

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Jonas Borgström
Date:
2015-01-03 @ 22:43
On 2015-01-03 23:24, Dmitry Astapov wrote:
> I actually believe that something else is a root cause:
> see https://github.com/jborg/attic/issues/163 for detailed description
> and possible fix.
I'm actually not quite sure that's the same thing. Alberto did not
mention anything about this being triggered by "attic list" on a
repository with a lot of archives.


>
> As for the files not fitting in memory, hash index in question is 700
> Mb, there is 1Gb ram(mostly unused), and when "attic created" runs I
> see that attic allocates 1.4Gb (does it always use twice the hash
> index size?) and swaps a bit, though it does not bother me much.
There's more than one hash index. Each repository has one (the index
file). But there's also on in the cache directory which is even bigger.
Attic can also temporarily use more ram when a hash index has to be
rebuilt/resized.

/ Jonas

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Dmitry Astapov
Date:
2015-01-03 @ 23:04
On Sat, Jan 3, 2015 at 10:43 PM, Jonas Borgström <jonas@borgstrom.se> wrote:

> On 2015-01-03 23:24, Dmitry Astapov wrote:
> > I actually believe that something else is a root cause:
> > see https://github.com/jborg/attic/issues/163 for detailed description
> > and possible fix.
> I'm actually not quite sure that's the same thing. Alberto did not
> mention anything about this being triggered by "attic list" on a
> repository with a lot of archives.
>

I re-read the email chain and I stand corrected - his issue indeed looks
like something different.

>
> > As for the files not fitting in memory, hash index in question is 700
> > Mb, there is 1Gb ram(mostly unused), and when "attic created" runs I
> > see that attic allocates 1.4Gb (does it always use twice the hash
> > index size?) and swaps a bit, though it does not bother me much.
> There's more than one hash index. Each repository has one (the index
> file). But there's also on in the cache directory which is even bigger.
> Attic can also temporarily use more ram when a hash index has to be
> rebuilt/resized.
>

Ah, makes sense. I am pretty sure that no resizing happens in my case, but
index file in the cache dir is of similar size (~680 Mb), which accounts
for all VSS I see (680+700 =~ 1400).


-- 
Dmitry Astapov

Re: [attic] [ANNOUNCE] Attic 0.14 Released

From:
Alberto Luaces
Date:
2015-05-19 @ 11:55
"Jonas Borgström" writes:

> On 2014-12-21 16:24, Dmitry Astapov wrote:
>> I could confirm that something looks odd after upgrading to 0.14. I
>> have a particular archive that attic is still able to back up to,
>> however, if I try to "list" it, I see that attic is rapidly allocating
>> tons of memory until it is killed after allocating about 4Gb of VSS.
>>
>> Box has 1Gb of physical RAM and 2Gb of swap.
>
> The obvious culprit in the 0.14 release is this change:
> HashIndex: Switch to a non-mmap based implementation:
> https://github.com/jborg/attic/commit/2f72b9f96001310ca4a81f8336545f2a3dd1de04
>
> Before this change Attic did not actually load the hash index files into
> memory but instead used mmap to access and update them.
> The benefit with that approach was that the files didn't actually need
> to fit into memory for this to work (but the performance would be very
> poor if they don't).
> But as some of you noticed the downside with this approach was that the
> OS could in some cases perform a lot more write operations than needed,
> especially if the system was low on ram.
> You could say the mmap() usage was a way for Attic to "swap" without
> using any swap space.
>
> The 0.14 approach is a more traditional malloc() based approach which
> should have a much more predictable behavior, and generally perform
> slightly better. But only as long as the system has enough free ram (or
> swap space) to contain the index data.
>
> Are you able to add more swap space to your system? i think given enough
> swap space Attic 0.14 should perform as good, or better than 0.13.

Unlike 0.14, Attic 0.15 and 0.16 work flawlessly backing up my system,
which does not have any swap space.  In addition, new versions work
noticeably faster.

Thank you!

--
Alberto