[opensuse-factory] Suggerence: use xz instead of gzip in "/etc/cron.daily/suse.de-backup-rpmdb"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The system script "/etc/cron.daily/suse.de-backup-rpmdb" uses gzip as compressor, when it could use something more modern like 'xz'. I changed it on my system and it works: # if gzip -9 < /var/lib/rpm/$PACKAGEDBFILE > $NEWNAME.gz; then if xz < /var/lib/rpm/$PACKAGEDBFILE > $NEWNAME.xz; then ... # rm -f $NEWNAME $NEWNAME.gz rm -f $NEWNAME $NEWNAME.xz It compresses to half the space (from 100 MB to 50 MB), and as there are several backups (I get 10) the saving is more important. What do you thing? The change is very easy to implement. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOkyAQACgkQtTMYHG2NR9WtxACbBApcNdkt5X5IOihn0U2CCsnu C1YAnAq4tC4+j9iV0Lyl9bmeyvT51la1 =fnRq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 20/06/14 19:47, Carlos E. R. escribió:
Hi,
The system script "/etc/cron.daily/suse.de-backup-rpmdb" uses gzip as compressor, when it could use something more modern like 'xz'. I changed it on my system and it works:
# if gzip -9 < /var/lib/rpm/$PACKAGEDBFILE > $NEWNAME.gz; then if xz < /var/lib/rpm/$PACKAGEDBFILE > $NEWNAME.xz; then ... # rm -f $NEWNAME $NEWNAME.gz rm -f $NEWNAME $NEWNAME.xz
It compresses to half the space (from 100 MB to 50 MB), and as there are several backups (I get 10) the saving is more important.
What do you thing? The change is very easy to implement.
Yeah, but it has to use pixz instead. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 21 Jun 2014 02:25, Cristian Rodríguez
El 20/06/14 19:47, Carlos E. R. escribió:
The system script "/etc/cron.daily/suse.de-backup-rpmdb" uses gzip as compressor, when it could use something more modern like 'xz'. I changed it on my system and it works: <snip> It compresses to half the space (from 100 MB to 50 MB), and as there are several backups (I get 10) the saving is more important.
What do you thing? The change is very easy to implement.
Yeah, but it has to use pixz instead.
(pixz = parallel, indexing version of xz) http://software.opensuse.org/package/pixz?search_term=pixz Well, it is in standard repo / medium, BUT it is not in default install pattern. So before you preach about using pixz, please make sure it get's installed in default pattern. Otherwise, I see no difficulties with pixz preferred above xz. Or do a select in the code: [CODE] PACKER=xz test -x /usr/bin/pixz && PACKER=pixz [/CODE] and use $PACKER in the script. - Yamaban.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 02:40, Yamaban wrote:
On Sat, 21 Jun 2014 02:25, Cristian Rodríguez <> wrote:
El 20/06/14 19:47, Carlos E. R. escribió:
Yeah, but it has to use pixz instead.
(pixz = parallel, indexing version of xz)
Ah, I understand. But then I think it should not be used. Reason: all CPU cores get used, affecting the entire system usage. Better to use just one core, so that the important tasks the users are running have the rest of the cpu cores fully available. Less impact. It does not matter that these cron jobs take longer. It could be a choice, but not the default, IMO. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOk1h4ACgkQtTMYHG2NR9Wo+wCfTHNSMye3JdNBryxpxbO+5gnp 7PAAn0fJ+LTuMbpm9SOwXQfKgOomlVpT =mDZ1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 21 Jun 2014 02:47, Carlos E. R.
On 2014-06-21 02:40, Yamaban wrote:
On Sat, 21 Jun 2014 02:25, Cristian Rodríguez <> wrote:
El 20/06/14 19:47, Carlos E. R. escribió:
Yeah, but it has to use pixz instead.
(pixz = parallel, indexing version of xz)
Ah, I understand. But then I think it should not be used.
Reason: all CPU cores get used, affecting the entire system usage. Better to use just one core, so that the important tasks the users are running have the rest of the cpu cores fully available. Less impact. It does not matter that these cron jobs take longer.
It could be a choice, but not the default, IMO.
Valid point, how about something similar to the locatedb update script: [CODE] nice -n 19 ionice -c 3 $PACKER ..... [/CODE] that should limit the impact of the PACKER on the system, no matter of xz or pixz are used. - Yamaban.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 03:03, Yamaban wrote:
On Sat, 21 Jun 2014 02:47, Carlos E. R.
wrote:
It could be a choice, but not the default, IMO.
Valid point, how about something similar to the locatedb update script:
[CODE] nice -n 19 ionice -c 3 $PACKER ..... [/CODE]
that should limit the impact of the PACKER on the system, no matter of xz or pixz are used.
That results in this task filling up all the remaining cpu power left by the primary tasks. Ie, the computer get used 100%. The user would not feel it, but it also has the side effect of heating the computer more and using more electricity (way more important on laptops). I do not have proof of this, but a certain task using a minute at 100% CPU uses more electricity than the same task done at 50% CPU (or rather at the lower frequency setting of the CPU) during 2 minutes. I see several possibilities. Using a configurable nice value. Using a configurable number of cores, or percent of total cores. Using cpulimit or equivalent tool (it works better than "nice"). Adding ionice -c 3 on config (useful for disk intensive tasks). And all periodic and intensive cron jobs could use these global settings. For the moment, I would be quite content with having this particular cronjob just using xz instead of gzip, same as logrotate does :-) It seems a trivial change to do. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOk4BQACgkQtTMYHG2NR9VEtwCdHNRn4YxhlJyz+GcHVSp6CQVt HZkAn1L2Oy2aamzzYt19jjicuqZACwpf =29z4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2014-06-21 03:29, Carlos E. R. wrote:
Valid point, how about something similar to the locatedb update script:
[CODE] nice -n 19 ionice -c 3 $PACKER ..... [/CODE]
that should limit the impact of the PACKER on the system, no matter of xz or pixz are used.
That results in this task filling up all the remaining cpu power left by the primary tasks. Ie, the computer get used 100%.
So what? logrotate has to take the same bullet. Modern processors go up to their TDP anyway, whether single or multiple cores are used, whether gzip or xz format is used, so pixz may just as well be used. (Though xz format tries harder than gzip.) This sounds like a good candidate for update-alternatives, by the way (mv xz original-xz; and making xz an u-a link). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 05:10, Jan Engelhardt wrote:
On Saturday 2014-06-21 03:29, Carlos E. R. wrote:
Valid point, how about something similar to the locatedb update script:
[CODE] nice -n 19 ionice -c 3 $PACKER ..... [/CODE]
that should limit the impact of the PACKER on the system, no matter of xz or pixz are used.
That results in this task filling up all the remaining cpu power left by the primary tasks. Ie, the computer get used 100%.
So what? logrotate has to take the same bullet. Modern processors go up to their TDP anyway, whether single or multiple cores are used, whether gzip or xz format is used, so pixz may just as well be used. (Though xz format tries harder than gzip.)
Not all processes run simultaneously on all cores (or several cores). Most of the background tasks use a single CPU core, which can max to 100%, without impacting the rest of the cores. That's my point, not to intentionally and by default use a compressor such as "pixz" on background, system, tasks.
This sounds like a good candidate for update-alternatives, by the way (mv xz original-xz; and making xz an u-a link).
Could be, but that would affect all compressing jobs run on the system. An alternative is define a compressor in sysconfig for all system tasks, or create a wrapper script that calls the compressor of choice, taking care of the different syntax of each one. On logrotate config you can easily choose a compressor, for instance. In this particular case, configuration is done in "/etc/sysconfig/backup". It would be possible to define the compressor there as a variable, and use it in the script. Let me see... we have, in "/etc/cron.daily/suse.de-backup-rpmdb", this section: if [ -f /etc/sysconfig/backup ] ; then . /etc/sysconfig/backup fi So, we could define in "/etc/sysconfig/backup": PACKER="gzip -9" PACKEREXT=".gz" or PACKER="xz" PACKEREXT="xz" And the script would become: if $PACKER < /var/lib/rpm/$PACKAGEDBFILE > $NEWNAME.$PACKEREXT; then ... rm -f $NEWNAME $NEWNAME.$PACKEREXT (untested yet) That way you can choose any compressor you like, as long as the syntax fits (the script uses the compressor in a pipe). This is still a minimal change, and you can use gzip, xz, or pixz, easily enough, on the choice of the administrator :-) Mmmm? :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOlY1gACgkQtTMYHG2NR9VqHwCdEEDUF7UVeJVJuGD1VeeEEqm7 NdsAnjOTecbNbCw44VGqsGbIxO9SLzyB =kcXy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 12:50, Carlos E. R. wrote:
(untested yet)
I just did, appears to work fine. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOlZfoACgkQtTMYHG2NR9VkugCfYLm8uAvPfdP2ABDICdmmwu1I sfsAni9XyRvORFR3rKxKUYMzxUafhFwA =I/Oe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Samstag, 21. Juni 2014, 03:29:56 schrieb Carlos E. R.:
[...] That results in this task filling up all the remaining cpu power left by the primary tasks. Ie, the computer get used 100%. The user would not feel it, but it also has the side effect of heating the computer more and using more electricity (way more important on laptops). I do not have proof of this, but a certain task using a minute at 100% CPU uses more electricity than the same task done at 50% CPU (or rather at the lower frequency setting of the CPU) during 2 minutes. [...]
No, the opposite is often true: | In summary, the only sensible way to use a CPU is to run it as fast as | possible in order to let it idle as much as possible, and drop the | frequency and voltage when it's not doing anything. The. Only. Sensible. | Way. http://mjg59.livejournal.com/88608.html (Discussion on http://lwn.net/Articles/281629/) The buzzword is "race to idle". Gruß Jan -- A closed mouth gathers no feet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 12:51, Jan Ritzerfeld wrote:
Am Samstag, 21. Juni 2014, 03:29:56 schrieb Carlos E. R.:
[...]
No, the opposite is often true: | In summary, the only sensible way to use a CPU is to run it as fast as | possible in order to let it idle as much as possible, and drop the | frequency and voltage when it's not doing anything. The. Only. Sensible. | Way. http://mjg59.livejournal.com/88608.html (Discussion on http://lwn.net/Articles/281629/) The buzzword is "race to idle".
Mmmm. :-? Got some new reading to do. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOlZa8ACgkQtTMYHG2NR9V1mQCdG0mXTmHJFSyLEBXVTUnPkyQW t7AAnjDIru2QIBj+oOFWYjBLwQa00Cy+ =9A3G -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.06.2014 03:29, schrieb Carlos E. R.:
That results in this task filling up all the remaining cpu power left by the primary tasks. Ie, the computer get used 100%. The user would not feel it, but it also has the side effect of heating the computer more and using more electricity (way more important on laptops). I do not have proof of this, but a certain task using a minute at 100% CPU uses more electricity than the same task done at 50% CPU (or rather at the lower frequency setting of the CPU) during 2 minutes.
The last I read about this issue, the general consent was that "race to idle" is the best power saving strategy: do what you have to do as fast as possible, then go to the lowest possible/usable power state. And yes, this was founded with facts (processor specifications and data sheets etc). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-23 13:17, Stefan Seyfried wrote:
Am 21.06.2014 03:29, schrieb Carlos E. R.:
That results in this task filling up all the remaining cpu power left by the primary tasks. Ie, the computer get used 100%. The user would not feel it, but it also has the side effect of heating the computer more and using more electricity (way more important on laptops). I do not have proof of this, but a certain task using a minute at 100% CPU uses more electricity than the same task done at 50% CPU (or rather at the lower frequency setting of the CPU) during 2 minutes.
The last I read about this issue, the general consent was that "race to idle" is the best power saving strategy: do what you have to do as fast as possible, then go to the lowest possible/usable power state.
And yes, this was founded with facts (processor specifications and data sheets etc).
Good to know. It contradicts what I knew, but things change :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOofj8ACgkQtTMYHG2NR9UjyACeOv8XfoWuMpuIG+3rFRvbeG5P C3oAnAuVl/TdOPy03RFvtxx8wuHsp4NJ =XRHg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2014-06-21 03:03, Yamaban wrote:
Valid point, how about something similar to the locatedb update script:
[CODE] nice -n 19 ionice -c 3 $PACKER ..... [/CODE]
that should limit the impact of the PACKER on the system, no matter of xz or pixz are used.
You should really use a cgroup instead, where you can define exact usage quanta. Since such already happens automatically (CONFIG_SCHED_AUTOGROUP), cron (and all its subprocesses) 's usage should be 1:n distributed with all logged-in users. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 05:12, Jan Engelhardt wrote:
You should really use a cgroup instead, where you can define exact usage quanta.
Since such already happens automatically (CONFIG_SCHED_AUTOGROUP), cron (and all its subprocesses) 's usage should be 1:n distributed with all logged-in users.
That's beyond my paycheck level :-) Could you point to a "cgroup for dummies" docu somewhere? ;-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOlZCsACgkQtTMYHG2NR9UbCwCeP+zYO5sE9oL96mhp545f50mC PFAAoIckbn67E3zX6dv2zzID8QLKcA6x =3mdz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 21 June 2014 12:53:31 Carlos E. R. wrote:
On 2014-06-21 05:12, Jan Engelhardt wrote:
You should really use a cgroup instead, where you can define exact usage quanta.
Since such already happens automatically (CONFIG_SCHED_AUTOGROUP), cron (and all its subprocesses) 's usage should be 1:n distributed with all logged-in users.
That's beyond my paycheck level :-)
Could you point to a "cgroup for dummies" docu somewhere? ;-)
cgroups in a systemd environment: http://0pointer.de/blog/projects/resources.html Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 21 Jun 2014 16:37, Stefan Brüns
On Saturday 21 June 2014 12:53:31 Carlos E. R. wrote:
On 2014-06-21 05:12, Jan Engelhardt wrote:
You should really use a cgroup instead, where you can define exact usage quanta.
Since such already happens automatically (CONFIG_SCHED_AUTOGROUP), cron (and all its subprocesses) 's usage should be 1:n distributed with all logged-in users.
That's beyond my paycheck level :-)
Could you point to a "cgroup for dummies" docu somewhere? ;-)
cgroups in a systemd environment: http://0pointer.de/blog/projects/resources.html
Well, even https://en.wikipedia.org/wiki/Cgroups is more helpfull than Lennart's attempt at documentation. In short: either use a 3-rd Party tool to get the cgroup set up (e.g. https://en.wikipedia.org/wiki/Lmctfy) or do your own setup with the tools from libcgroup. [sarcasm] Yeah, suuuuper handy. and ohhh sooo weeelll documented. -- NOT ! [/sarcasm] Eitherway, a tool that allows to limit cpu, disk-io, net-io, and mem in one go is not available in default repo ATM. (e.g. [limit-tool-name] \ -c [cpu-limits:cores,percentage,nice] -d [disk-io-limits] \ -n [net-io-limits] -m [mem-limits] <command and args to run>]) Maybe this could be the incentive to include such a tool in default repo, or even put it into the default install pattern. - Yamaban.
On Saturday 21 June 2014 19:36:21 Yamaban wrote:
On Sat, 21 Jun 2014 16:37, Stefan Brüns
wrote: On Saturday 21 June 2014 12:53:31 Carlos E. R. wrote:
On 2014-06-21 05:12, Jan Engelhardt wrote:
You should really use a cgroup instead, where you can define exact usage quanta.
Since such already happens automatically (CONFIG_SCHED_AUTOGROUP), cron (and all its subprocesses) 's usage should be 1:n distributed with all logged-in users.
That's beyond my paycheck level :-)
Could you point to a "cgroup for dummies" docu somewhere? ;-)
cgroups in a systemd environment: http://0pointer.de/blog/projects/resources.html
Well, even https://en.wikipedia.org/wiki/Cgroups is more helpfull than Lennart's attempt at documentation.
[] you know the difference between a blog post and a man page
[sarcasm] Yeah, suuuuper handy. and ohhh sooo weeelll documented. -- NOT ! [/sarcasm]
man systemd.resource-control man systemd.scope man systemd.slice
Eitherway, a tool that allows to limit cpu, disk-io, net-io, and mem in one go is not available in default repo ATM. (e.g. [limit-tool-name] \ -c [cpu-limits:cores,percentage,nice] -d [disk-io-limits] \ -n [net-io-limits] -m [mem-limits] <command and args to run>])
man systemd-run Regards, Stefan PS: Stop ranting and educate yourself -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 22 Jun 2014 03:04, Stefan Brüns
On Saturday 21 June 2014 19:36:21 Yamaban wrote:
On Sat, 21 Jun 2014 16:37, Stefan Brüns
wrote: On Saturday 21 June 2014 12:53:31 Carlos E. R. wrote:
On 2014-06-21 05:12, Jan Engelhardt wrote: <snip> [sarcasm] Yeah, suuuuper handy. and ohhh sooo weeelll documented. -- NOT ! [/sarcasm]
man systemd.resource-control man systemd.scope man systemd.slice
Eitherway, a tool that allows to limit cpu, disk-io, net-io, and mem in one go is not available in default repo ATM. (e.g. [limit-tool-name] \ -c [cpu-limits:cores,percentage,nice] -d [disk-io-limits] \ -n [net-io-limits] -m [mem-limits] <command and args to run>])
man systemd-run
My rant is pointed to the fact that there is no such tool for easy usage (one tool, one man-page, and done). For that we would need a successor for nice and ionice as shown above. To use systemd in any way, kind, or shape you need to study at least 5 man-pages, 4 blogs, 3 wiki, and be a regular at a in-depth mailing list to accomplish anything that does not blow up into your face at least on the first try. For "systemd-run" you need at least systemd version 209. (found at https://wiki.archlinux.org/index.php/Systemd/User) It is not available prior to that, so OSS 13.1 and prior is out. The information which version of systemd includes which command with what exact ability is very well hidden from casual search. FYI: http://software.opensuse.org/package/systemd still shows: openSUSE Factory official release 44 Base:System 210 Something is "not really right" in generating the "official release" line. - Yamaban.
El 20/06/14 20:47, Carlos E. R. escribió:
On 2014-06-21 02:40, Yamaban wrote:
On Sat, 21 Jun 2014 02:25, Cristian Rodríguez <> wrote:
El 20/06/14 19:47, Carlos E. R. escribió:
Yeah, but it has to use pixz instead.
(pixz = parallel, indexing version of xz)
Ah, I understand. But then I think it should not be used.
Reason: all CPU cores get used, affecting the entire system usage.
If it really affects the system overall usability, it is a bug.. in the kernel... -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-21 03:43, Cristian Rodríguez wrote:
El 20/06/14 20:47, Carlos E. R. escribió:
On 2014-06-21 02:40, Yamaban wrote:
On Sat, 21 Jun 2014 02:25, Cristian Rodríguez <> wrote:
El 20/06/14 19:47, Carlos E. R. escribió:
Yeah, but it has to use pixz instead.
(pixz = parallel, indexing version of xz)
Ah, I understand. But then I think it should not be used.
Reason: all CPU cores get used, affecting the entire system usage.
If it really affects the system overall usability, it is a bug.. in the kernel...
No, not really. It is a task using all the CPU power it can find, competing with other tasks that the user needs right now, this instant, making them slower. Consider: if you are running, say, a video conversion tool or math simulation, or anything needing power, a background job that is not really in a hurry to be completed runs simultaneously, also wanting to use all the cpu power (and it runs as root user). The result is that the user job would get about half of the total cpu power, and the cron job the other half. So the important user task runs slower. It is simple math :-) It really does not matter if the daily cronjobs take longer to finish, just that they do it efficiently. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOk5kkACgkQtTMYHG2NR9WPaACfcLfys9if0PCkVjS+0+2ppa/4 26UAn0FCheku/Or01CL6OtUyIxfeCKS8 =NA4p -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-06-21 02:25, Cristian Rodríguez wrote:
El 20/06/14 19:47, Carlos E. R. escribió:
Yeah, but it has to use pixz instead.
Why? I don't have that one installed, and the new script appears to work correctly. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 21.06.2014 02:25, schrieb Cristian Rodríguez:
El 20/06/14 19:47, Carlos E. R. escribió:
It compresses to half the space (from 100 MB to 50 MB), and as there are several backups (I get 10) the saving is more important.
What do you thing? The change is very easy to implement.
Yeah, but it has to use pixz instead.
I think it is not a good idea to use something that will happily saturate all my cores for a background maintenance job. Usually noone will wait until this job is finished, because it will just be running in the background, but the customers trying to access the web shop on that machine at the same time will be happy to have some spare CPU cycles left. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Carlos E. R.
-
Carlos E. R.
-
Cristian Rodríguez
-
Jan Engelhardt
-
Jan Ritzerfeld
-
Stefan Brüns
-
Stefan Seyfried
-
Yamaban