Check out the implementation of
https://issues.apache.org/jira/browse/ACCUMULO-3793. You could do something
similar and start your process with 'nice' instead of 'numactl'.
> -Original Message-
> From: Christopher [mailto:ctubb...@apache.org]
> Sent: Monday, August 17, 2015 7:15 PM
> To:
All of the components that you need to perform point in time recovery of an
Accumulo instance exist already. I have been working on a tool[1] in my copious
amounts of free time to integrate them into something usable, but it doesn’t
actually use the files in the trash. My approach is to let yo
I haven't heard of anybody setting the niceness of the Accumulo
processes before. Are you experiencing a lot of CPU contention on your
nodes, such that you need to prioritize processes?
However, if you do this, I think you actually want HDFS to -2,
Accumulo to -1, and Mapreduce tasks 0 (you'll hav
More like a mapreduce task process.
--
Jeff Kubina
410-988-4436
On Mon, Aug 17, 2015 at 5:33 PM, William Slacum wrote:
> By "Hadoop" do you mean a Yarn NodeManager process?
>
> On Mon, Aug 17, 2015 at 4:21 PM, Jeff Kubina
> wrote:
>
>> On each of the processing nodes in our cluster we have r
By "Hadoop" do you mean a Yarn NodeManager process?
On Mon, Aug 17, 2015 at 4:21 PM, Jeff Kubina wrote:
> On each of the processing nodes in our cluster we have running 1) HDFS
> (datanode), 2) Accumulo (tablet server), and 3) Hadoop. Since Accumulo
> depends on the HDFS, and Hadoop depends on t
On each of the processing nodes in our cluster we have running 1) HDFS
(datanode), 2) Accumulo (tablet server), and 3) Hadoop. Since Accumulo
depends on the HDFS, and Hadoop depends on the HDFS and sometimes on
Accumulo, we are considering setting the niceness of HDFS to 0 (the current
value), Accu
Some advanced recovery steps are documented[1], but there is no sort of
"fix it for you" tool.
It's probably a good idea to either set "fs.trash.interval" and/or
"fs.trash.checkpoint.interval" in core-site.xml to be representative of
the available HDFS space you have, or just turn off trash an
Ok, I can the see the benefit of being able to recovery data. Is this
process documented? And is there any kind of user-friendly tool for it?
On Mon, Aug 17, 2015 at 4:11 PM, wrote:
>
> It's not temporary files, it's any file that has been compacted away. If
> you keep files around longer tha
It's not temporary files, it's any file that has been compacted away. If you
keep files around longer than { dfs.namenode.checkpoint.period}, then you have
a chance to recover in case your most recent checkpoint is corrupt.
- Original Message -
From: "James Hughes"
To: user@accumulo
If something goes wrong (i.e. somebody accidentally issues a big delete),
then having the Trash around makes recovery plausible.
On Mon, Aug 17, 2015 at 2:57 PM, James Hughes wrote:
> Hi all,
>
> From reading about the Accumulo GC, it sounds like temporary files are
> routinely deleted during GC
Hi all,
>From reading about the Accumulo GC, it sounds like temporary files are
routinely deleted during GC cycles. In a small testing environment, I've
the HDFS Accumulo user's .Trash folder have 10s of gigabytes of data.
Is there any reason that the default value for gc.trash.ignore is false?
11 matches
Mail list logo
