[systemd-devel] Support for large applications

Michał Zegan webczat_200 at poczta.onet.pl
Wed Feb 17 14:15:57 UTC 2016


-----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 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 compression is
>> enabled. As the situation is now, there is a period of time where
>> it is impossible to know what is happening.
>> 
>> (I saw that 229 improves core dumps, but did not see this
>> specifically)
> 
> The coredump is logged afterwards because that's the only way to 
> include all information (including the compressed file name) in
> one log message. But there are two changes which might mitigate the
> problem: - semi-recently we switched to lz4, which compresses
> significantly faster, have you tried that?
> 
> - recently the responsibility of writing core dumps was split out
> to a service. I'm not sure how that influences the time when the
> log message is written.
> 
>> 2. parallel compression of core dumps
>> 
>> As well as consuming all of memory, we also consume all cpus.
>> Once we dump core we may as well use those cores for compressing
>> the huge dump.
> 
> This should be implemented in the compression library. The
> compressor does not seem to be threaded, but it was we would try to
> make use of it. OTOH, single-threaded lz4 is able to produce
> ~500MB/s of compressed output, so you'd need a really fast disk to
> go above that.
> 
>> 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 prefer
>> to have the service report progress to systemd so that it knows
>> that startup is still in progress.

This requires cooperation from the service process, but is probably
possible.
> 
> Zbyszek _______________________________________________ 
> systemd-devel mailing list systemd-devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWxICYAAoJEHb1CzgxXKwYDooP/2OAx9WYfFuKDDrtuQ4KNRi/
X+20724fBeSJ7NZs/JieLjVYwAIRkHD/5OXzW2S5HZAvilrQwUCiSCZfADNB+0Tv
189noHuR4l9PopMUoVl4ay13W+1O93x2Tq3SPxe0SmkQEl9tWzKYYeS98q80a5gE
179fvQtkyDfcoKLp5npxmXaQZpqarl6FH3z41hHzWJdTZKiOiAFtYYSxNgzDRvar
cBGSTsb8NLGMZBA0B0NLGWNNLMIq2qZbIJ600I1Buu6OkBGq0dyikFUpEdWdW8+k
SVOGLrNll8wxpzd8Kxm9CmoQmzw/Bgo9eeX2kpuubOd85IBfauI/vzpTXw4geWzw
PuMh9NetEWpNTx6fqbpJ+yVSygldJ1HRKeTjmM6kt527D8yRvNOGdsQEgzqxi1l3
3aWohll4FDL0f5CpnCixZH8ZNwTePIacQi3Btd76LK9m8Fu4cV9yi70L4tY6dewQ
7XZEYK77s4p8R5UpyGsx2X/rtkZI6nGNRejWSzkAfsLBb0VL5TxqJyw5goP+ATIZ
HDJz8pPN2hxDLzQ9ou70sG1O3Pt87dF4BjHqWCeoMKQJ8Z0LfhlLz44EVX/EYfjy
0A298GlPgw+Jhb8lm3e/eFnbfl3iHYaQmtewXwOhcSKfHB13TGAkPwW6YTFafVDG
JDjiS2mB3v4ONwuu2gCs
=S4f+
-----END PGP SIGNATURE-----


More information about the systemd-devel mailing list