Re: [systemd-devel] Support for large applications

2016-03-19 Thread Avi Kivity
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

Re: [systemd-devel] Support for large applications

2016-03-19 Thread Avi Kivity
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

Re: [systemd-devel] Support for large applications

2016-02-23 Thread Lennart Poettering
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: > > >

Re: [systemd-devel] Support for large applications

2016-02-23 Thread Lennart Poettering
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

Re: [systemd-devel] Support for large applications

2016-02-23 Thread Lennart Poettering
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

Re: [systemd-devel] Support for large applications

2016-02-23 Thread Lennart Poettering
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

Re: [systemd-devel] Support for large applications

2016-02-23 Thread Umut Tezduyar Lindskog
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

Re: [systemd-devel] Support for large applications

2016-02-19 Thread Zbigniew Jędrzejewski-Szmek
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: > > > > >

Re: [systemd-devel] Support for large applications

2016-02-19 Thread Tomasz Torcz
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

Re: [systemd-devel] Support for large applications

2016-02-19 Thread Michal Sekletar
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 >

Re: [systemd-devel] Support for large applications

2016-02-19 Thread Zbigniew Jędrzejewski-Szmek
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

Re: [systemd-devel] Support for large applications

2016-02-19 Thread Michal Sekletar
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

Re: [systemd-devel] Support for large applications

2016-02-18 Thread Jonathan de Boyne Pollard
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

Re: [systemd-devel] Support for large applications

2016-02-17 Thread Avi Kivity
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

Re: [systemd-devel] Support for large applications

2016-02-17 Thread Michał Zegan
-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

Re: [systemd-devel] Support for large applications

2016-02-17 Thread Zbigniew Jędrzejewski-Szmek
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

[systemd-devel] Support for large applications

2016-02-17 Thread Avi Kivity
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