[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