On 02/18/2016 08:28 PM, Lennart Poettering wrote:
On Wed, 17.02.16 14:35, Avi Kivity (a...@scylladb.com) wrote:
We are using systemd to supervise our NoSQL database and are generally
happy.
Thank you for the feedback! We are always interested in good feedback
like yours.
A few things will
On 02/19/2016 03:24 PM, Michal Sekletar wrote:
On Fri, Feb 19, 2016 at 1:49 PM, Zbigniew Jędrzejewski-Szmek
wrote:
I don't think there's a way around the issue short of allowing
watchdog during startup. Databases which do long recovery are a bit
special, most programs
On Fri, 19.02.16 15:13, Tomasz Torcz (to...@pipebreaker.pl) wrote:
> On Fri, Feb 19, 2016 at 12:49:53PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Feb 19, 2016 at 01:42:12PM +0100, Michal Sekletar wrote:
> > > On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
> > >
On Wed, 17.02.16 20:47, Avi Kivity (a...@scylladb.com) wrote:
> btw I hope that with this change the service is only restarted after the
> dump is complete, or oom is likely.
Yeah, the crashed process actually stays around as long as we don't
close the pipe the kernel passes to us where the
On Wed, 17.02.16 14:35, Avi Kivity (a...@scylladb.com) wrote:
> We are using systemd to supervise our NoSQL database and are generally
> happy.
Thank you for the feedback! We are always interested in good feedback
like yours.
> A few things will help even more:
>
> 1. log core dumps
On Fri, 19.02.16 12:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Fri, Feb 19, 2016 at 01:42:12PM +0100, Michal Sekletar wrote:
> > On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
> >
> > > 3. watchdog during startup
> > >
> > > Sometimes we need to
On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
> We are using systemd to supervise our NoSQL database and are generally
> happy.
>
> A few things will help even more:
>
> 1. log core dumps immediately rather than after the dump completes
>
> A database will often consume
On Fri, Feb 19, 2016 at 03:13:43PM +0100, Tomasz Torcz wrote:
> On Fri, Feb 19, 2016 at 12:49:53PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Feb 19, 2016 at 01:42:12PM +0100, Michal Sekletar wrote:
> > > On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
> > >
> >
On Fri, Feb 19, 2016 at 12:49:53PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Feb 19, 2016 at 01:42:12PM +0100, Michal Sekletar wrote:
> > On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
> >
> > > 3. watchdog during startup
> > >
> > > Sometimes we need to perform
On Fri, Feb 19, 2016 at 1:49 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> I don't think there's a way around the issue short of allowing
> watchdog during startup. Databases which do long recovery are a bit
> special, most programs don't exhibit this kind of behaviour, but maybe
>
On Fri, Feb 19, 2016 at 01:42:12PM +0100, Michal Sekletar wrote:
> On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
>
> > 3. watchdog during startup
> >
> > Sometimes we need to perform expensive operations during startup (log
> > replay, rebuild from network replica) before
On Wed, Feb 17, 2016 at 1:35 PM, Avi Kivity wrote:
> 3. watchdog during startup
>
> Sometimes we need to perform expensive operations during startup (log
> replay, rebuild from network replica) before we can start serving. Rather
> than configure a huge start timeout, I'd
Avi Kivity:
We are using systemd to supervise our NoSQL database [...]
Sometimes [it needs] to perform expensive operations during startup
(log replay, rebuild from network replica) before we can start
serving. Rather than configure a huge start timeout, I'd prefer to
have the service
On 02/17/2016 03:56 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
We are using systemd to supervise our NoSQL database and are
generally happy.
A few things will help even more:
1. log core dumps immediately rather than after the dump
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi, I'll add to this:
W dniu 17.02.2016 o 14:56, Zbigniew Jędrzejewski-Szmek pisze:
> On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
>> We are using systemd to supervise our NoSQL database and are
>> generally happy.
>>
>> A few
On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
> We are using systemd to supervise our NoSQL database and are
> generally happy.
>
> A few things will help even more:
>
> 1. log core dumps immediately rather than after the dump completes
>
> A database will often consume all memory
We are using systemd to supervise our NoSQL database and are generally
happy.
A few things will help even more:
1. log core dumps immediately rather than after the dump completes
A database will often consume all memory on the machine; dumping 120GB
can take a lot of time, especially if
17 matches
Mail list logo