View previous topic :: View next topic |
Author |
Message |
SwordArMor n00b
Joined: 21 Feb 2015 Posts: 56 Location: Bretagne
|
Posted: Tue May 12, 2015 10:33 am Post subject: |
|
|
Je suis aussi de cette école. Ma machine la plus ancienne a quinze ans et elle commence tout juste à montrer quelques signes de fatigue. |
|
Back to top |
|
|
DuF Advocate
Joined: 09 Dec 2002 Posts: 2687 Location: Paris
|
Posted: Tue May 12, 2015 2:19 pm Post subject: |
|
|
moi je n'ai pas eu le choix, mon alimentation avait grillé (ça fait toujours bizarre une fumée qui s'échappe avec une odeur de plastique fondue) et avait en même temps grillé des composants de la carte mère. Du coup j'avais pris une configuration adaptée à mon usage (puissante brute mais carte vidéo de base).
Mais pareil les composants ont 3 ans et je ne pense pas changer dans les années à venir (si possible minimum une décennie ) et j'espère que libreoffice n'augmentera pas ses besoins |
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8708 Location: ~Brussels - Belgique
|
Posted: Tue May 12, 2015 5:46 pm Post subject: |
|
|
Il y a des alternatives à libreoffice telles abiword et gnumeric, mais pour du "powerpoint", je ne vois pas trop. Et libreoffice est moins médiocre comparé aux sus-nommés concernant la compatibilité avec MS Office. _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
Leander256 l33t
Joined: 05 Jul 2003 Posts: 910 Location: Singapour
|
Posted: Tue May 12, 2015 6:07 pm Post subject: |
|
|
Il faut dire que la puissance de calcul nécessaire pour la plupart des tâches courantes est largement suffisante depuis quelques années. Et quand une tâche prenait du temps, c'était assez souvent à cause du disque dur, je pense que tous les gens qui ont fait l'expérience d'une transition HDD -> SSD sur une même machine comprendront très bien de quoi je veux parler!
D'ailleurs pour en revenir au sujet quelqu'un l'a déjà mentionné mais maintenant ça me paraît évident, si le temps de compilation de libreoffice fait un bond très brusque, c'est très probablement lié à l'utilisation de la swap. Et là encore on peut mettre en cause GCC qui peut prendre des tonnes de mémoire pour compiler certains bouts de C++. Je n'ai rien contre GCC, soit dit en passant!
Quote: | Il y a des alternatives à libreoffice telles abiword et gnumeric, mais pour du "powerpoint", je ne vois pas trop. Et libreoffice est moins médiocre comparé aux sus-nommés concernant la compatibilité avec MS Office. |
Peut-être Calligra? Je n'ai pas vraiment eu l'occasion de m'en servir jusqu'à présent, mais cette suite me semble intéressante. Bon par contre c'est du KDE, ce n'est pas forcément plus léger à compiler |
|
Back to top |
|
|
341438 n00b
Joined: 01 May 2015 Posts: 47
|
Posted: Wed May 13, 2015 11:55 am Post subject: |
|
|
@DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
à combien de ram ? |
|
Back to top |
|
|
sebB l33t
Joined: 02 Mar 2011 Posts: 806 Location: S.O. France
|
Posted: Wed May 13, 2015 2:52 pm Post subject: |
|
|
Effectivement je suis en train de me tater pour repasser sous calligra (qui de mémoire gère les powerpoint).
Je pense aussi que libreoffice est devenu gourmand en mémoire mais ca n'explique pas mon écart de compil (moi je me suis pris 6h en plus d'un coup).
Surtout quand je vois que kopp avec son Core 2 et ses 2G de ram compile plus vite.
Et cette différence je ne l'ai que sur libreoffice. |
|
Back to top |
|
|
kopp Advocate
Joined: 09 Apr 2004 Posts: 2885 Location: Grenoble, France
|
Posted: Wed May 13, 2015 6:44 pm Post subject: |
|
|
Tristelune wrote: | @DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
à combien de ram ? |
Il est passé à 32, c'est écrit ... de 16 je suppose.
SInon la question c'est surtout : tu compiles en tmpfs Duf ?
Sinon, pour rappel :
Code: | Tue Dec 5 21:26:28 2006 >>> app-office/openoffice-2.0.4
merge time: 2 hours, 21 minutes and 58 seconds. |
sur la même machine...
En même temps à l'époque Firefox (2 !) prenait entre 8 et 30 minutes... sans tmpfs. Maintenant il lui faut 2h en tmps, mais je suppose que ça swap pas mal sur ma machine ... |
|
Back to top |
|
|
341438 n00b
Joined: 01 May 2015 Posts: 47
|
Posted: Wed May 13, 2015 8:57 pm Post subject: |
|
|
kopp wrote: |
Il est passé à 32, c'est écrit ... de 16 je suppose.
|
Je suis un malin, je n'ai pas eu la curiosité de regarder ce qu'il y avait dans la deuxième partie du code.
Merci pour l'info! |
|
Back to top |
|
|
DuF Advocate
Joined: 09 Dec 2002 Posts: 2687 Location: Paris
|
Posted: Thu May 14, 2015 11:38 am Post subject: |
|
|
kopp wrote: | Tristelune wrote: | @DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
à combien de ram ? |
Il est passé à 32, c'est écrit ... de 16 je suppose.
SInon la question c'est surtout : tu compiles en tmpfs Duf ?
(...) |
En fait je suis passé de 4 à 32 et je fais pointer PORTAGE_TMPDIR vers /tmp qui est un tmpfs.
Pour firefox sinon, depuis le début de l'année ça s'est drôlement amélioré chez moi :
Quote: | Thu Jan 15 20:03:21 2015 >>> www-client/firefox-35.0
merge time: 26 minutes and 31 seconds.
Fri Feb 27 23:27:43 2015 >>> www-client/firefox-36.0
merge time: 18 minutes and 5 seconds.
Sun Mar 15 17:43:01 2015 >>> www-client/firefox-36.0.1
merge time: 17 minutes and 20 seconds.
Mon Mar 30 13:29:58 2015 >>> www-client/firefox-36.0.4
merge time: 12 minutes and 46 seconds.
Wed Apr 8 22:28:37 2015 >>> www-client/firefox-37.0.1
merge time: 12 minutes and 45 seconds.
Fri May 1 11:25:11 2015 >>> www-client/firefox-37.0.2
merge time: 13 minutes and 51 seconds.
|
|
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8708 Location: ~Brussels - Belgique
|
Posted: Thu May 14, 2015 7:17 pm Post subject: |
|
|
La dernière mouture a pris 18h sur mon atom, contre 6-7 heures il y a quelques mois... via distcc à chaque fois _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
sebB l33t
Joined: 02 Mar 2011 Posts: 806 Location: S.O. France
|
Posted: Thu May 28, 2015 9:59 am Post subject: |
|
|
Code: | Sun Feb 15 20:56:34 2015 >>> app-office/libreoffice-4.3.5.2
merge time: 3 hours, 10 minutes and 44 seconds.
Sun Apr 19 18:47:34 2015 >>> app-office/libreoffice-4.4.1.2
merge time: 8 hours, 41 minutes and 59 seconds.
Wen May 27 20:11:56 2015 >>> app-office/libreoffice-4.4.3.2
merge time: 5 hours, 52 minutes and 38 seconds. |
Bon ca s'améliore avec les versions.
Je retombe un peu dans la moyenne à la vue de vos stats.
A croire que la version 4.4.1.2 avait un soucis chez moi. |
|
Back to top |
|
|
SwordArMor n00b
Joined: 21 Feb 2015 Posts: 56 Location: Bretagne
|
Posted: Thu May 28, 2015 11:31 am Post subject: |
|
|
Tu n’es pas le seul à avoir une temps de compilation plus long pour la 4.4.1.2 :
Code: | Tue Apr 7 13:56:27 2015 >>> app-office/libreoffice-4.3.5.2
merge time: 1 hour, 35 minutes and 23 seconds.
Mon Apr 13 15:52:35 2015 >>> app-office/libreoffice-4.4.1.2
merge time: 2 hours, 4 minutes and 9 seconds.
|
|
|
Back to top |
|
|
augustin Guru
Joined: 23 Feb 2015 Posts: 318
|
Posted: Thu May 28, 2015 7:09 pm Post subject: |
|
|
Code: |
Victoria config # genlop -t libreoffice
* app-office/libreoffice
Wed Mar 4 22:38:50 2015 >>> app-office/libreoffice-4.3.5.2
merge time: 2 hours, 10 minutes and 43 seconds.
Thu Mar 5 04:34:54 2015 >>> app-office/libreoffice-4.3.5.2
merge time: 3 hours, 22 minutes and 47 seconds.
Fri Apr 17 19:23:28 2015 >>> app-office/libreoffice-4.4.1.2
merge time: 2 hours, 23 minutes and 33 seconds.
Thu May 28 10:38:32 2015 >>> app-office/libreoffice-4.4.3.2
merge time: 2 hours, 56 minutes and 5 seconds.
|
AMD Phenom(tm) II X4 955 Processor |
|
Back to top |
|
|
DuF Advocate
Joined: 09 Dec 2002 Posts: 2687 Location: Paris
|
Posted: Sat May 30, 2015 3:02 pm Post subject: |
|
|
Code: | Wed Apr 8 23:38:19 2015 >>> app-office/libreoffice-4.3.5.2
merge time: 1 hour, 9 minutes and 42 seconds.
Sat Apr 18 16:28:25 2015 >>> app-office/libreoffice-4.4.1.2
merge time: 1 hour, 22 minutes and 34 seconds.
Sat May 30 16:58:33 2015 >>> app-office/libreoffice-4.4.3.2
merge time: 1 hour, 26 minutes and 33 seconds.
|
On ne compile pas tous la même chose ni avec les mêmes éléments (gcc-4.8.4 chez moi) |
|
Back to top |
|
|
sebB l33t
Joined: 02 Mar 2011 Posts: 806 Location: S.O. France
|
Posted: Fri Jul 17, 2015 3:32 pm Post subject: |
|
|
Y'a t'il un moyen de gérer les accés disque lors de la compil de libreoffice?
Mon load average grimpe à 12/13 alors que dans mon make.conf je l'ai limité à 8.
On peut voir que ce n'est pas la charge de mes cpu qui coince.
Mon disque est en activité constante et mon ordi inutilisable pendant 8h car il rame.
Y'a-t-il mieux que ext4 pour compiler si le probleme vient de là?
Certe je peux lancer les compil la nuit mais j'aimerais bien comprendre.
Stats compil libreoffice.
top
Code: | 1 user, load average: 7,93, 8,83, 8,81
Tasks: 237 total, 2 running, 235 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,1 us, 3,0 sy, 60,1 ni, 8,1 id, 28,6 wa, 0,0 hi, 0,1 si, 0,0 st
KiB Mem: 3967952 total, 3878408 used, 89544 free, 496 buffers
KiB Swap: 8388604 total, 1629216 used, 6759388 free. 24144 cached Mem |
iostat
Code: | avg-cpu: %user %nice %system %iowait %steal %idle
0,13 0,75 0,25 22,43 0,00 76,44
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 19,00 0,00 146,00 2,00 2608,00 888,00 47,24 21,16 969,47 890,53 6732,00 6,76 100,00
dm-0 0,00 0,00 42,00 0,00 2220,00 0,00 105,71 9,15 1565,69 1565,69 0,00 23,81 100,00
dm-1 0,00 0,00 122,00 0,00 488,00 0,00 8,00 76,33 12846,57 596,30 0,00 8,20 100,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-4 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 |
iostat -x 1
Code: | avg-cpu: %user %nice %system %iowait %steal %idle
2,01 38,98 2,95 14,05 0,00 42,00
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 33,81 315,53 695,21 22248798 49020176
dm-0 6,71 126,08 8,05 8890125 567352
dm-1 177,07 134,22 574,06 9463756 40477876
dm-2 13,89 46,00 74,63 3243573 5262580
dm-3 0,90 8,78 12,77 618901 900328
dm-4 5,66 0,41 25,70 29257 1811868 |
make.conf
Code: | CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j9 -l8"
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"
PORTAGE_ELOG_CLASSES="log warn error info"
PORTAGE_ELOG_SYSTEM="echo:log,warn save:log,warn,error,info syslog:error"
PORTAGE_NICENESS=19
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}" |
|
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Mon Jul 20, 2015 9:10 am Post subject: |
|
|
sebB wrote: | Y'a t'il un moyen de gérer les accés disque lors de la compil de libreoffice?
Mon load average grimpe à 12/13 alors que dans mon make.conf je l'ai limité à 8.
[...]
Code: | CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j9 -l8"
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"
PORTAGE_ELOG_CLASSES="log warn error info"
PORTAGE_ELOG_SYSTEM="echo:log,warn save:log,warn,error,info syslog:error"
PORTAGE_NICENESS=19
PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}" |
|
Tel que je vois les choses, tu as un poil trop trituré ta configuration portage (classique et chronique pour un utilisateur gentoo) et tu as fini par faire du "ricing"
4 fois 9 threads n'est peut être pas ce que tu attendais, mais c'est ce que tu as configuré.
man emerge:
Quote: | -j [JOBS], --jobs[=JOBS]
Specifies the number of packages to build simultaneously. |
Donc 4 packages en parallèle, avec chacun 9 threads... Ca pourrait peut être venir de là. Le disque n'est pas le tueur, mais une victime
J'aime bien ton idée de jouer avec une limite de load, mais si jamais tu as une machine qui n'est pas un desktop et a une charge CPU non nulle en dehors de l'activité de portage, tu risques d'avoir des temps de compilation/emerge assez lamentables.
Ce que j'essaierais: si tu souhaites rester à jouer avec le load limit, ne garde que la config MAKEOPTS qui s'applique à chaque package. Et si tu as une machine ayant des traitements CPU constants (un serveur par exemple), garde uniquement le PORTAGE_NICENESS en retirant les load-limit (si tu considères qu'une MAJ doit être traitée en un temps raisonnable). Mais bon, c'est peut être un poil moins fun, je te l'accorde, libre à toi de rechercher une combinaison plus amusante. _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
sebB l33t
Joined: 02 Mar 2011 Posts: 806 Location: S.O. France
|
Posted: Mon Jul 20, 2015 4:42 pm Post subject: |
|
|
Effectivement j'ai fais pas mal de test, et certains trucs ont été ajoutés car c'était la mode....
Je ne savais pas que que les threads se multipliaient avec les packages.
Je pensais:
Quote: | MAKEOPTS, dans mon cas maxi 9 threads et limite load à 8
EMERGE_DEFAULT_OPTS, on dit au package suivant de démarer si 1 threads est libre et que le load est inférieur à 4.
D'ou paquet A utilise 6 threads et load < 4 donc paquet B demarre avec les 3 threads qui sont dispo.
|
Je viens de faire un tas de tests notamment avec gcc 4.9.3 et aucune issue avec libreoffice.
firefox + thunderbird sont passés sans probleme (aucun freeze).
J'ai juste laissé dans mon make.conf, MAKEOPTS=j(n)
Je viens de me rendre compte qu'un autre paquet à les mêmes "symptomes", sigil.
Avec un j>4 mon systeme ne répond plus et le load grimpe à 15 même si je tente de le limiter (d'ailleurs ca semble pas marcher ce -jn -ln). Celui là en plus est compilé en tmpfs.
Si je stoppe la compil, la diode de mon dd reste allumée et mon systeme est inutilisable (rien dans top) même après un rm du tmp. Ca revient à la normale au but de 5 minutes.
Code: | Mon Nov 17 23:20:42 2014 >>> app-text/sigil-0.6.2
merge time: 7 minutes and 28 seconds.
Tue Dec 30 09:51:14 2014 >>> app-text/sigil-0.6.2
merge time: 6 minutes and 53 seconds.
Mon Jul 20 00:58:19 2015 >>> app-text/sigil-0.6.2
merge time: 33 minutes and 1 second. |
top
Code: | 1 user, load average: 14,67, 11,14, 8,07
Tasks: 234 total, 10 running, 224 sleeping, 0 stopped, 0 zombie
%Cpu(s): 98,8 us, 1,2 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 3967952 total, 3518376 used, 449576 free, 143488 buffers
KiB Swap: 8388604 total, 2664 used, 8385940 free. 1249752 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10809 portage 20 0 412556 384896 17040 R 95,9 9,7 3:16.67 cc1plus
11704 portage 20 0 111352 84740 17308 R 93,2 2,1 0:06.23 cc1plus
11680 portage 20 0 127032 101408 17308 R 86,9 2,6 0:10.82 cc1plus
11712 portage 20 0 111600 85304 17388 R 86,6 2,1 0:05.65 cc1plus
11696 portage 20 0 111624 87020 17264 R 82,6 2,2 0:06.60 cc1plus
11708 portage 20 0 113972 88940 17308 R 82,3 2,2 0:05.72 cc1plus
11664 portage 20 0 138428 114044 17380 R 79,9 2,9 0:12.91 cc1plus
11721 portage 20 0 96960 67676 14072 R 75,0 1,7 0:02.26 cc1plus
11725 portage 20 0 85776 54336 12160 R 45,8 1,4 0:01.38 cc1plus |
Je suis en train de réinstaller gcc 4.7 pour voir. Après je seche.
Au pire je regarderais si y'a pas moyen de passer un -jn a certains paquets dans le package.env
EDIT: gcc 4.7 ne résoud rien. J'ai donc créé un fichier j4.conf en attendant mieux. |
|
Back to top |
|
|
El_Goretto Moderator
Joined: 29 May 2004 Posts: 3169 Location: Paris
|
Posted: Tue Jul 21, 2015 12:06 pm Post subject: |
|
|
sebB wrote: | J'ai juste laissé dans mon make.conf, MAKEOPTS=j(n)
|
Sage décision, mieux vaut repartir de 0 et rajouter petit à petit d'éventuels tunings.
sebB wrote: | Je viens de me rendre compte qu'un autre paquet à les mêmes "symptomes", sigil.
Avec un j>4 mon systeme ne répond plus et le load grimpe à 15 même si je tente de le limiter (d'ailleurs ca semble pas marcher ce -jn -ln). Celui là en plus est compilé en tmpfs.
Si je stoppe la compil, la diode de mon dd reste allumée et mon systeme est inutilisable (rien dans top) même après un rm du tmp. Ca revient à la normale au but de 5 minutes. |
J'allais dire: cela ressemble fichtrement aus symptômes d'une machine qui swape comme une malheureuse. Et tes différents "screenshots" de top tendent à le prouver. Il va peut être falloir refaire le tour de tes différents montages tmpfs si tu en as, voire redevenir humble du côté de ce que tu demandes à ta machine
Pour rappel, on parle quand même de la compilation d'un paquet obèse de chez obèse, OpenOffice _________________ -TrueNAS & jails: µ-serv Gen8 E3-1260L, 16Go ECC + µ-serv N40L, 10Go ECC
-Réseau: APU2C4 (OpenWRT) + GS726Tv3 + 2x GS108Tv2 + Archer C5v1 (OpenWRT) |
|
Back to top |
|
|
sebB l33t
Joined: 02 Mar 2011 Posts: 806 Location: S.O. France
|
Posted: Fri Jul 24, 2015 7:58 pm Post subject: |
|
|
Après plusieurs test, j'ai des paquets qui ne passe plus avec un j>4 alors qu'avant aucun soucis.
Si pour libreoffice je suis ok, pour sigil je comprends pas.
En même temps je vais rester en j4 car je ne perds que 10 min sur les grosses compil comparé à mon j9.
Par contre es tu sur de ca?
Quote: | Tel que je vois les choses, tu as un poil trop trituré ta configuration portage (classique et chronique pour un utilisateur gentoo) et tu as fini par faire du "ricing"
4 fois 9 threads n'est peut être pas ce que tu attendais, mais c'est ce que tu as configuré. |
Car moi je pensais
MAKEOPTS=-j9, dans mon cas maxi 9 threads
EMERGE_DEFAULT_OPTS=--jobs=4 --load-average=4, on dit au package suivant de démarer si 1 threads est libre et que le load est inférieur à 4.
J'en déduisait que si paquet A utilise 6 threads et load < 4 donc paquet B demarre avec les 3 threads qui sont dispo. |
|
Back to top |
|
|
kopp Advocate
Joined: 09 Apr 2004 Posts: 2885 Location: Grenoble, France
|
Posted: Sun Aug 16, 2015 8:35 am Post subject: |
|
|
Pour moi, le MAKEOPTS ne concerne qu'un seul paquet à la fois, pas une option globale.
Tu n'auras peut-être pas 4 paquets en même temps à 9 threads, mais c'est possible qu'il y en ait plusieurs quand même. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|