Déjà tenté. Ça ne fait presque rien parce que le problème est que updatedb est un goret en terme d'occupation mémoire. Ça swappe et lorsque ça se met à swapper, un ionice n'arrange rien. La question sous-jacente est de savoir pourquoi updatedb bouffe autant de mémoire. J'ai comme dans l'idée que le truc n'est pas optimisé, du moins pour l'occupation de la mémoire (je vois monter updatedb à plus de 300 Mo... d'occupation mémoire).
Déjà tenté. Ça ne fait presque rien parce que le problème est que updatedb est un goret en terme d'occupation mémoire. Ça swappe et lorsque ça se met à swapper, un ionice n'arrange rien. La question sous-jacente est de savoir pourquoi updatedb bouffe autant de mémoire. J'ai comme dans l'idée que le truc n'est pas optimisé, du moins pour l'occupation de la mémoire (je vois monter updatedb à plus de 300 Mo... d'occupation mémoire).
Déjà tenté. Ça ne fait presque rien parce que le problème est que updatedb est un goret en terme d'occupation mémoire. Ça swappe et lorsque ça se met à swapper, un ionice n'arrange rien. La question sous-jacente est de savoir pourquoi updatedb bouffe autant de mémoire. J'ai comme dans l'idée que le truc n'est pas optimisé, du moins pour l'occupation de la mémoire (je vois monter updatedb à plus de 300 Mo... d'occupation mémoire).
Ça permet d'avoir des fonctionnements différents. init 5 avec
X, init 2 ou 5 en fonctionnement serveur classique, 2a avec un
fonctionnement classique plus un serveur de fax par exemple...
Pour un poste de travail, ça ne sert à rien. Pour un serveur,
ça peut être utile.
Pas du tout. Pour les serveurs, je laisse les Linux mourir de
leur belle mort et lorsque je remplace un serveur, c'est par un
NetBSD.
Pour les postes de travail, en fonction de l'architecture, c'est du
Net ou du Free. Je bricole aussi avec du L4 ou du VMS, mais c'est un
autre sport :-P
Ça permet d'avoir des fonctionnements différents. init 5 avec
X, init 2 ou 5 en fonctionnement serveur classique, 2a avec un
fonctionnement classique plus un serveur de fax par exemple...
Pour un poste de travail, ça ne sert à rien. Pour un serveur,
ça peut être utile.
Pas du tout. Pour les serveurs, je laisse les Linux mourir de
leur belle mort et lorsque je remplace un serveur, c'est par un
NetBSD.
Pour les postes de travail, en fonction de l'architecture, c'est du
Net ou du Free. Je bricole aussi avec du L4 ou du VMS, mais c'est un
autre sport :-P
Ça permet d'avoir des fonctionnements différents. init 5 avec
X, init 2 ou 5 en fonctionnement serveur classique, 2a avec un
fonctionnement classique plus un serveur de fax par exemple...
Pour un poste de travail, ça ne sert à rien. Pour un serveur,
ça peut être utile.
Pas du tout. Pour les serveurs, je laisse les Linux mourir de
leur belle mort et lorsque je remplace un serveur, c'est par un
NetBSD.
Pour les postes de travail, en fonction de l'architecture, c'est du
Net ou du Free. Je bricole aussi avec du L4 ou du VMS, mais c'est un
autre sport :-P
[autre chose que du Linux.]Pas du tout. Pour les serveurs, je laisse les Linux mourir de
leur belle mort et lorsque je remplace un serveur, c'est par un
NetBSD.
Intéressant, mais l'absence de solution de virtualisation légère ne te
contrarie pas ?
[...]Pour les postes de travail, en fonction de l'architecture, c'est du
Net ou du Free. Je bricole aussi avec du L4 ou du VMS, mais c'est un
autre sport :-P
Connais pas, vais aller voir ça ;)
[autre chose que du Linux.]
Pas du tout. Pour les serveurs, je laisse les Linux mourir de
leur belle mort et lorsque je remplace un serveur, c'est par un
NetBSD.
Intéressant, mais l'absence de solution de virtualisation légère ne te
contrarie pas ?
[...]
Pour les postes de travail, en fonction de l'architecture, c'est du
Net ou du Free. Je bricole aussi avec du L4 ou du VMS, mais c'est un
autre sport :-P
Connais pas, vais aller voir ça ;)
[autre chose que du Linux.]Pas du tout. Pour les serveurs, je laisse les Linux mourir de
leur belle mort et lorsque je remplace un serveur, c'est par un
NetBSD.
Intéressant, mais l'absence de solution de virtualisation légère ne te
contrarie pas ?
[...]Pour les postes de travail, en fonction de l'architecture, c'est du
Net ou du Free. Je bricole aussi avec du L4 ou du VMS, mais c'est un
autre sport :-P
Connais pas, vais aller voir ça ;)
maderios a écrit :On 10/22/2014 05:31 PM, BERTRAND Joël wrote:Au démarrage, tu charges tout un tas de saletés dont tu n'as que
faire. Et comme le noyau sait mieux que toi comment il doit gérer la
mémoire, il préalloue des tas de zones et se met à swapper immédiatement
alors même que tu lui as indiqué une valeur swapiness intéressante. En
fait, Linux à la fin des années 1990 était vendu comme un système léger
et fiable. Il est encore à peu près fiable (sur x86) mais plus du tout
léger.
Ce n'est pas spécifique à Linux. J'ai installé et utilisé Freebsd, c'est
exactement le même problème. La seule solution d'avoir un noyau
optimisé pour son propre système, c'est de le compiler soi-même, ce que
je fais depuis 15 ans et il n'y a pas photo avec les noyaux "officiels".
Mouais. J'ai installé récemment un FreeBSD sur un Acer Aspire 1700
(un P4). FreeBSD vient nu, sans scories inutiles. L'installeur vient
même sans X. C'est à toi de rajouter ce que tu veux.
Quant à recompiler les noyaux, franchement, je ne vois pas bien la
différence entre un noyau précompilé et un autre que je compile aux
petits oignons. Autant sur quelques systèmes bien spécifiques ça peut se
justifier (du style -mtune=ev56 sur alpha), autant sur du x86, c'est une
perte de temps. Et ce n'est pas ce qui te fait gagner en occupation
mémoire. Mieux vaut triturer les paramètres avec sysctl.
maderios a écrit :
On 10/22/2014 05:31 PM, BERTRAND Joël wrote:
Au démarrage, tu charges tout un tas de saletés dont tu n'as que
faire. Et comme le noyau sait mieux que toi comment il doit gérer la
mémoire, il préalloue des tas de zones et se met à swapper immédiatement
alors même que tu lui as indiqué une valeur swapiness intéressante. En
fait, Linux à la fin des années 1990 était vendu comme un système léger
et fiable. Il est encore à peu près fiable (sur x86) mais plus du tout
léger.
Ce n'est pas spécifique à Linux. J'ai installé et utilisé Freebsd, c'est
exactement le même problème. La seule solution d'avoir un noyau
optimisé pour son propre système, c'est de le compiler soi-même, ce que
je fais depuis 15 ans et il n'y a pas photo avec les noyaux "officiels".
Mouais. J'ai installé récemment un FreeBSD sur un Acer Aspire 1700
(un P4). FreeBSD vient nu, sans scories inutiles. L'installeur vient
même sans X. C'est à toi de rajouter ce que tu veux.
Quant à recompiler les noyaux, franchement, je ne vois pas bien la
différence entre un noyau précompilé et un autre que je compile aux
petits oignons. Autant sur quelques systèmes bien spécifiques ça peut se
justifier (du style -mtune=ev56 sur alpha), autant sur du x86, c'est une
perte de temps. Et ce n'est pas ce qui te fait gagner en occupation
mémoire. Mieux vaut triturer les paramètres avec sysctl.
maderios a écrit :On 10/22/2014 05:31 PM, BERTRAND Joël wrote:Au démarrage, tu charges tout un tas de saletés dont tu n'as que
faire. Et comme le noyau sait mieux que toi comment il doit gérer la
mémoire, il préalloue des tas de zones et se met à swapper immédiatement
alors même que tu lui as indiqué une valeur swapiness intéressante. En
fait, Linux à la fin des années 1990 était vendu comme un système léger
et fiable. Il est encore à peu près fiable (sur x86) mais plus du tout
léger.
Ce n'est pas spécifique à Linux. J'ai installé et utilisé Freebsd, c'est
exactement le même problème. La seule solution d'avoir un noyau
optimisé pour son propre système, c'est de le compiler soi-même, ce que
je fais depuis 15 ans et il n'y a pas photo avec les noyaux "officiels".
Mouais. J'ai installé récemment un FreeBSD sur un Acer Aspire 1700
(un P4). FreeBSD vient nu, sans scories inutiles. L'installeur vient
même sans X. C'est à toi de rajouter ce que tu veux.
Quant à recompiler les noyaux, franchement, je ne vois pas bien la
différence entre un noyau précompilé et un autre que je compile aux
petits oignons. Autant sur quelques systèmes bien spécifiques ça peut se
justifier (du style -mtune=ev56 sur alpha), autant sur du x86, c'est une
perte de temps. Et ce n'est pas ce qui te fait gagner en occupation
mémoire. Mieux vaut triturer les paramètres avec sysctl.
[â¦]
> â parallélisation du boot ;
La question est toujours la même. à quel besoin est-ce q ue
ça répond. Le seul que je vois est un démarrage plus r apide en
complexifiant à mort la gestion du parallélisme (avec tous
les effets de bord que cela implique).
[â¦]
> â gestion des dépendances entre scripts dâinit ;
Idem. Debian gérait très bien cela avec SysV.
[â¦]
Le bricolage est indépendant de l'outil.
D'ailleurs, bizarrement, systemd récupère les scripts da ns
/etc/init.d.
[â¦]
> http://wiki.debian.org/systemd
> http://en.wikipedia.org/wiki/Systemd
> http://0pointer.de/blog/projects/why.html
Je ne parle pas de cela.
[â¦]
SVC est moisi parce qu'il embarque une base sql pour gérer
les daemons, parce qu'il fait un tas de choses dans le dos de
l'utilisateur et sait mieux que lui ce qui est bon pour lui.
SVC est pourri parce que les logs sont aussi en partie
binaire. Bizarrement, SVC me semble la source d'inspiration
de systemd.
[â¦]
dbus et propre dans la même phrase, je n'aurais vraiment pas
osé.
C'est peut-être de l'éprouvé, mais c'est parfaitement
inutile sauf si l'on part du principe qu'il faille au moins 1
Go de mémoire pour démarrer un système.
[â¦]
Et il n'y a aucune raison pour que systemd soit plus
maintenable que SysV.
>> Avec systemd, on mélange allègrement le démarrage d u
>> système
>> et son fonctionnement une fois démarré, ce qui est un au tre
>> problème. et qui devrait être traité différemm ent.
>>
> Nâimporte quoi (moi aussi, je peux être péremp toire).
Tu peux, mais il n'empêche que c'est le cas. Tu l'as mêm e
écrit toi-même un peu plus haut.
[â¦]
Parce qu'on refuse de séparer le démarrage de l'OS et so n
fonctionnement une fois lancé. On en revient toujours à la
même chose. C'est même très exactement pour cela qu'il y a eu
un fork de systemd (useless).
[â¦]
[â¦]
> â parallélisation du boot ;
La question est toujours la même. à quel besoin est-ce q ue
ça répond. Le seul que je vois est un démarrage plus r apide en
complexifiant à mort la gestion du parallélisme (avec tous
les effets de bord que cela implique).
[â¦]
> â gestion des dépendances entre scripts dâinit ;
Idem. Debian gérait très bien cela avec SysV.
[â¦]
Le bricolage est indépendant de l'outil.
D'ailleurs, bizarrement, systemd récupère les scripts da ns
/etc/init.d.
[â¦]
> http://wiki.debian.org/systemd
> http://en.wikipedia.org/wiki/Systemd
> http://0pointer.de/blog/projects/why.html
Je ne parle pas de cela.
[â¦]
SVC est moisi parce qu'il embarque une base sql pour gérer
les daemons, parce qu'il fait un tas de choses dans le dos de
l'utilisateur et sait mieux que lui ce qui est bon pour lui.
SVC est pourri parce que les logs sont aussi en partie
binaire. Bizarrement, SVC me semble la source d'inspiration
de systemd.
[â¦]
dbus et propre dans la même phrase, je n'aurais vraiment pas
osé.
C'est peut-être de l'éprouvé, mais c'est parfaitement
inutile sauf si l'on part du principe qu'il faille au moins 1
Go de mémoire pour démarrer un système.
[â¦]
Et il n'y a aucune raison pour que systemd soit plus
maintenable que SysV.
>> Avec systemd, on mélange allègrement le démarrage d u
>> système
>> et son fonctionnement une fois démarré, ce qui est un au tre
>> problème. et qui devrait être traité différemm ent.
>>
> Nâimporte quoi (moi aussi, je peux être péremp toire).
Tu peux, mais il n'empêche que c'est le cas. Tu l'as mêm e
écrit toi-même un peu plus haut.
[â¦]
Parce qu'on refuse de séparer le démarrage de l'OS et so n
fonctionnement une fois lancé. On en revient toujours à la
même chose. C'est même très exactement pour cela qu'il y a eu
un fork de systemd (useless).
[â¦]
[â¦]
> â parallélisation du boot ;
La question est toujours la même. à quel besoin est-ce q ue
ça répond. Le seul que je vois est un démarrage plus r apide en
complexifiant à mort la gestion du parallélisme (avec tous
les effets de bord que cela implique).
[â¦]
> â gestion des dépendances entre scripts dâinit ;
Idem. Debian gérait très bien cela avec SysV.
[â¦]
Le bricolage est indépendant de l'outil.
D'ailleurs, bizarrement, systemd récupère les scripts da ns
/etc/init.d.
[â¦]
> http://wiki.debian.org/systemd
> http://en.wikipedia.org/wiki/Systemd
> http://0pointer.de/blog/projects/why.html
Je ne parle pas de cela.
[â¦]
SVC est moisi parce qu'il embarque une base sql pour gérer
les daemons, parce qu'il fait un tas de choses dans le dos de
l'utilisateur et sait mieux que lui ce qui est bon pour lui.
SVC est pourri parce que les logs sont aussi en partie
binaire. Bizarrement, SVC me semble la source d'inspiration
de systemd.
[â¦]
dbus et propre dans la même phrase, je n'aurais vraiment pas
osé.
C'est peut-être de l'éprouvé, mais c'est parfaitement
inutile sauf si l'on part du principe qu'il faille au moins 1
Go de mémoire pour démarrer un système.
[â¦]
Et il n'y a aucune raison pour que systemd soit plus
maintenable que SysV.
>> Avec systemd, on mélange allègrement le démarrage d u
>> système
>> et son fonctionnement une fois démarré, ce qui est un au tre
>> problème. et qui devrait être traité différemm ent.
>>
> Nâimporte quoi (moi aussi, je peux être péremp toire).
Tu peux, mais il n'empêche que c'est le cas. Tu l'as mêm e
écrit toi-même un peu plus haut.
[â¦]
Parce qu'on refuse de séparer le démarrage de l'OS et so n
fonctionnement une fois lancé. On en revient toujours à la
même chose. C'est même très exactement pour cela qu'il y a eu
un fork de systemd (useless).
[â¦]
C'est simple, le noyau fourni par la distribution est compilé pour
convenir à tous les utilisateurs/configurations possibles et
imaginables. Ceci implique qu'une multitude de trucs
optionnels/inutiles sont chargés en dur, avec pour conséquence un
alourdissement du système. Il suffit de visualiser la conf du noyau
officiel pour se rendre compte de son embonpoint. Un noyau personnalisé
et adapté rend le système plus réactif, c'est tout du moins ce que j'ai
constaté.
Par ailleurs, dans la même démarche, on peut passer au stade suivant,
compiler tout le système avec Gentoo: gain en performances mais gros
investissement temps...
C'est simple, le noyau fourni par la distribution est compilé pour
convenir à tous les utilisateurs/configurations possibles et
imaginables. Ceci implique qu'une multitude de trucs
optionnels/inutiles sont chargés en dur, avec pour conséquence un
alourdissement du système. Il suffit de visualiser la conf du noyau
officiel pour se rendre compte de son embonpoint. Un noyau personnalisé
et adapté rend le système plus réactif, c'est tout du moins ce que j'ai
constaté.
Par ailleurs, dans la même démarche, on peut passer au stade suivant,
compiler tout le système avec Gentoo: gain en performances mais gros
investissement temps...
C'est simple, le noyau fourni par la distribution est compilé pour
convenir à tous les utilisateurs/configurations possibles et
imaginables. Ceci implique qu'une multitude de trucs
optionnels/inutiles sont chargés en dur, avec pour conséquence un
alourdissement du système. Il suffit de visualiser la conf du noyau
officiel pour se rendre compte de son embonpoint. Un noyau personnalisé
et adapté rend le système plus réactif, c'est tout du moins ce que j'ai
constaté.
Par ailleurs, dans la même démarche, on peut passer au stade suivant,
compiler tout le système avec Gentoo: gain en performances mais gros
investissement temps...
dbus et propre dans la même phrase, je n'aurais vraiment pas osé.
C'est peut-être de l'éprouvé, mais c'est parfaitement inutile sauf
si l'on part du principe qu'il faille au moins 1 Go de mémoire pour
démarrer un système.
dbus et propre dans la même phrase, je n'aurais vraiment pas osé.
C'est peut-être de l'éprouvé, mais c'est parfaitement inutile sauf
si l'on part du principe qu'il faille au moins 1 Go de mémoire pour
démarrer un système.
dbus et propre dans la même phrase, je n'aurais vraiment pas osé.
C'est peut-être de l'éprouvé, mais c'est parfaitement inutile sauf
si l'on part du principe qu'il faille au moins 1 Go de mémoire pour
démarrer un système.
Gaël a écrit :
Je crois de plus en plus que le but ultime de systemd est de
"faire comme Windows", démarrage rapide,
Gaël a écrit :
Je crois de plus en plus que le but ultime de systemd est de
"faire comme Windows", démarrage rapide,
Gaël a écrit :
Je crois de plus en plus que le but ultime de systemd est de
"faire comme Windows", démarrage rapide,
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 21/10/2014 13:49, BERTRAND Joël a écrit :
> Gaël a écrit :
> Je crois de plus en plus que le but ultime de systemd est de
> "faire comme Windows", démarrage rapide,
Je vois ça un peu partout dans ce fil: systemd pour un démarrage
rapide... ???
J'ai un systemV et le boot prend moins de 10s (~7s) dès que grb lance
le boot, jusqu'à l'écran d'accueil de lightdm.
S'identifier prend 4s pour obtenir le bureau xfce
Que vouloir de plus?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 21/10/2014 13:49, BERTRAND Joël a écrit :
> Gaël a écrit :
> Je crois de plus en plus que le but ultime de systemd est de
> "faire comme Windows", démarrage rapide,
Je vois ça un peu partout dans ce fil: systemd pour un démarrage
rapide... ???
J'ai un systemV et le boot prend moins de 10s (~7s) dès que grb lance
le boot, jusqu'à l'écran d'accueil de lightdm.
S'identifier prend 4s pour obtenir le bureau xfce
Que vouloir de plus?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 21/10/2014 13:49, BERTRAND Joël a écrit :
> Gaël a écrit :
> Je crois de plus en plus que le but ultime de systemd est de
> "faire comme Windows", démarrage rapide,
Je vois ça un peu partout dans ce fil: systemd pour un démarrage
rapide... ???
J'ai un systemV et le boot prend moins de 10s (~7s) dès que grb lance
le boot, jusqu'à l'écran d'accueil de lightdm.
S'identifier prend 4s pour obtenir le bureau xfce
Que vouloir de plus?