l'indien wrote in message :Un serveur bien fait, son main, c'est:
int main (...)
{
if (fork() == 0) {
daemonize();
real_main();
}
return 0;
}
Je ne suis pas d'accord. Outre que je partage en partie les idées de djb sur
le point précis du passage en démon des serveurs, je considère que même si
le serveur se démonise lui-même, il doit tout d'abord acquérir une bonne
certitude de pouvoir tourner, entre autres parser son fichier de config,
lier les ports s'il veut écouter, etc. Sans ça, repérer une erreur de
lancement est péniblissime.
Si ça augmente le temps de boot, il est temps de remplacer ton 286 !
Même comme ça, ça ralentit le processus de boot. Dans real_main, il va quand
même y avoir quelques trucs, comme par exemple la lecture d'un fichier de
config, le chargement d'éventuelles données, la génération de clefs de
session, ou que sais-je. Même si ça a lieu après le fork, ceci aura lieu en
concurrence avec le reste du processus de boot, pour le temps CPU et surtout
pour le transfert depuis le disque. Même si ce n'est pas du 100%, ça n'est
pas négligeable pour autant.
l'indien wrote in message <pan.2005.03.14.23.45.30.704822@magic.fr>:
Un serveur bien fait, son main, c'est:
int main (...)
{
if (fork() == 0) {
daemonize();
real_main();
}
return 0;
}
Je ne suis pas d'accord. Outre que je partage en partie les idées de djb sur
le point précis du passage en démon des serveurs, je considère que même si
le serveur se démonise lui-même, il doit tout d'abord acquérir une bonne
certitude de pouvoir tourner, entre autres parser son fichier de config,
lier les ports s'il veut écouter, etc. Sans ça, repérer une erreur de
lancement est péniblissime.
Si ça augmente le temps de boot, il est temps de remplacer ton 286 !
Même comme ça, ça ralentit le processus de boot. Dans real_main, il va quand
même y avoir quelques trucs, comme par exemple la lecture d'un fichier de
config, le chargement d'éventuelles données, la génération de clefs de
session, ou que sais-je. Même si ça a lieu après le fork, ceci aura lieu en
concurrence avec le reste du processus de boot, pour le temps CPU et surtout
pour le transfert depuis le disque. Même si ce n'est pas du 100%, ça n'est
pas négligeable pour autant.
l'indien wrote in message :Un serveur bien fait, son main, c'est:
int main (...)
{
if (fork() == 0) {
daemonize();
real_main();
}
return 0;
}
Je ne suis pas d'accord. Outre que je partage en partie les idées de djb sur
le point précis du passage en démon des serveurs, je considère que même si
le serveur se démonise lui-même, il doit tout d'abord acquérir une bonne
certitude de pouvoir tourner, entre autres parser son fichier de config,
lier les ports s'il veut écouter, etc. Sans ça, repérer une erreur de
lancement est péniblissime.
Si ça augmente le temps de boot, il est temps de remplacer ton 286 !
Même comme ça, ça ralentit le processus de boot. Dans real_main, il va quand
même y avoir quelques trucs, comme par exemple la lecture d'un fichier de
config, le chargement d'éventuelles données, la génération de clefs de
session, ou que sais-je. Même si ça a lieu après le fork, ceci aura lieu en
concurrence avec le reste du processus de boot, pour le temps CPU et surtout
pour le transfert depuis le disque. Même si ce n'est pas du 100%, ça n'est
pas négligeable pour autant.
S'attaquer à ce problème serait un bienfait et ferait tomber les temps
de boot à quelques secondes.
Il suffirait de gérer les dépendances
entre services, ce qui n'est pas bien difficile dans la plupart des cas...
Ca ralentirait si le process de boot utilisait le CPU de façon intensive.
Or, tu peux le vérifier, on est loin de consomer 100% du CPU durant le
boot, sur une machine moderne. Donc, paralléliser les tâches quand c'est
possible accélèrerait grandement le boot.
S'attaquer à ce problème serait un bienfait et ferait tomber les temps
de boot à quelques secondes.
Il suffirait de gérer les dépendances
entre services, ce qui n'est pas bien difficile dans la plupart des cas...
Ca ralentirait si le process de boot utilisait le CPU de façon intensive.
Or, tu peux le vérifier, on est loin de consomer 100% du CPU durant le
boot, sur une machine moderne. Donc, paralléliser les tâches quand c'est
possible accélèrerait grandement le boot.
S'attaquer à ce problème serait un bienfait et ferait tomber les temps
de boot à quelques secondes.
Il suffirait de gérer les dépendances
entre services, ce qui n'est pas bien difficile dans la plupart des cas...
Ca ralentirait si le process de boot utilisait le CPU de façon intensive.
Or, tu peux le vérifier, on est loin de consomer 100% du CPU durant le
boot, sur une machine moderne. Donc, paralléliser les tâches quand c'est
possible accélèrerait grandement le boot.
l'indien wrote in message :S'attaquer à ce problème serait un bienfait et ferait tomber les temps
de boot à quelques secondes.
La mailing-list Supervision <URL: http://www.skarnet.org/lists/ > est dédiée
à ce sujet, si ça intéresse du monde.
Il suffirait de gérer les dépendances
entre services, ce qui n'est pas bien difficile dans la plupart des cas...
Le problème est que les services eux-mêmes n'ont pas de mécanisme pour
notifier quand ils sont prêts. On en est réduits à des heuristiques pour
savoir s'ils ont fini de lire leur config et enfin lié les ports qu'ils
doivent lier. Il n'est pas rare de trouver des sleep dans les scripts d'init
à cause de ça.
Ca ralentirait si le process de boot utilisait le CPU de façon intensive.
Or, tu peux le vérifier, on est loin de consomer 100% du CPU durant le
boot, sur une machine moderne. Donc, paralléliser les tâches quand c'est
possible accélèrerait grandement le boot.
Oui mais non. S'ils n'utilisent pas le CPU, c'est presque toujours parce
qu'ils sont en attente de disque (parfois c'est en attente de réseau, mais
c'est bien plus rare), ce qui ralentit aussi le boot, et même plus puisque
le scheduling des I/O est moins bon que celui du temps CPU.
Évidemment, il peut y avoir du parallélisme, un processus qui bouffe
du CPU pendant que l'autre attend le disque, donc la perte de temps
n'est pas de 100%, mais elle est bien réelle.
l'indien wrote in message <pan.2005.03.15.12.35.02.487427@magic.fr>:
S'attaquer à ce problème serait un bienfait et ferait tomber les temps
de boot à quelques secondes.
La mailing-list Supervision <URL: http://www.skarnet.org/lists/ > est dédiée
à ce sujet, si ça intéresse du monde.
Il suffirait de gérer les dépendances
entre services, ce qui n'est pas bien difficile dans la plupart des cas...
Le problème est que les services eux-mêmes n'ont pas de mécanisme pour
notifier quand ils sont prêts. On en est réduits à des heuristiques pour
savoir s'ils ont fini de lire leur config et enfin lié les ports qu'ils
doivent lier. Il n'est pas rare de trouver des sleep dans les scripts d'init
à cause de ça.
Ca ralentirait si le process de boot utilisait le CPU de façon intensive.
Or, tu peux le vérifier, on est loin de consomer 100% du CPU durant le
boot, sur une machine moderne. Donc, paralléliser les tâches quand c'est
possible accélèrerait grandement le boot.
Oui mais non. S'ils n'utilisent pas le CPU, c'est presque toujours parce
qu'ils sont en attente de disque (parfois c'est en attente de réseau, mais
c'est bien plus rare), ce qui ralentit aussi le boot, et même plus puisque
le scheduling des I/O est moins bon que celui du temps CPU.
Évidemment, il peut y avoir du parallélisme, un processus qui bouffe
du CPU pendant que l'autre attend le disque, donc la perte de temps
n'est pas de 100%, mais elle est bien réelle.
l'indien wrote in message :S'attaquer à ce problème serait un bienfait et ferait tomber les temps
de boot à quelques secondes.
La mailing-list Supervision <URL: http://www.skarnet.org/lists/ > est dédiée
à ce sujet, si ça intéresse du monde.
Il suffirait de gérer les dépendances
entre services, ce qui n'est pas bien difficile dans la plupart des cas...
Le problème est que les services eux-mêmes n'ont pas de mécanisme pour
notifier quand ils sont prêts. On en est réduits à des heuristiques pour
savoir s'ils ont fini de lire leur config et enfin lié les ports qu'ils
doivent lier. Il n'est pas rare de trouver des sleep dans les scripts d'init
à cause de ça.
Ca ralentirait si le process de boot utilisait le CPU de façon intensive.
Or, tu peux le vérifier, on est loin de consomer 100% du CPU durant le
boot, sur une machine moderne. Donc, paralléliser les tâches quand c'est
possible accélèrerait grandement le boot.
Oui mais non. S'ils n'utilisent pas le CPU, c'est presque toujours parce
qu'ils sont en attente de disque (parfois c'est en attente de réseau, mais
c'est bien plus rare), ce qui ralentit aussi le boot, et même plus puisque
le scheduling des I/O est moins bon que celui du temps CPU.
Évidemment, il peut y avoir du parallélisme, un processus qui bouffe
du CPU pendant que l'autre attend le disque, donc la perte de temps
n'est pas de 100%, mais elle est bien réelle.
Voilà. On peut sans doute réduire le temps de boot de plus de 50% en
faisant celà. Grosso-modo, le temps de boot devrait être la somme des
temps d'accès disque (puisque c'est le goulot d'étranglement)
nécessaire au démarage de tous les services plus un petit overhead lié
à la gestion qui se doit d'être négligeable et un overhead du aux
dépendances qui, lui, peut réellement être très significatif.
Voilà. On peut sans doute réduire le temps de boot de plus de 50% en
faisant celà. Grosso-modo, le temps de boot devrait être la somme des
temps d'accès disque (puisque c'est le goulot d'étranglement)
nécessaire au démarage de tous les services plus un petit overhead lié
à la gestion qui se doit d'être négligeable et un overhead du aux
dépendances qui, lui, peut réellement être très significatif.
Voilà. On peut sans doute réduire le temps de boot de plus de 50% en
faisant celà. Grosso-modo, le temps de boot devrait être la somme des
temps d'accès disque (puisque c'est le goulot d'étranglement)
nécessaire au démarage de tous les services plus un petit overhead lié
à la gestion qui se doit d'être négligeable et un overhead du aux
dépendances qui, lui, peut réellement être très significatif.
Je souhaiterais débuter avec Linux Mandrake 10.1 mais mon pc est déjà
ancien.
Config : Céléron 700 Mhz
128 Mo Ram
HD 40 Go + HD 3.2 Go
Est - ce un minimum suffisant ou faut il voir plus grand ?
J'avais un Pentium3 800 MHz avec 128Mo de RAM. C'est un ordinateur
allumé 24h/24 qui fait tourner un serveur samba, et principalement deux
serveurs X11, chacun avec icewm comme gestionnaire de fenêtres. Sur l'un
des serveurs sont ouverts plusieurs Mozilla, un aMsn (client msn), un
eboard qui pompe plusieurs dizaines de Mo de mémoire. Sur l'autre tourne
en permanence un Mozilla, pas mal de terminaux, et plusieurs fenêtres
d'éditeur de texte.
Eh bien, pour tout dire, 128Mo, c'est carrément limite pour cette
utilisation. Je viens tout juste de passer à 256Mo, et là, c'est le
bonheur relatif. On n'entend plus une seule fois le disque dur swapper.
Je te conseille donc d'essayer de te procurer une barrette
supplémentaire de mémoire vive, ça ne peut pas faire de mal, surtout si
tu veux utiliser des bureaux tels que Gnome, voire KDE.
Pour le processeur, aucun problème, c'est une bête de course :), à moins
que tu veuilles faire du calculs brut.
--
#!/bin/bash # usage: bash .sig '' 'subject' 'content'
O(){ echo -e "${1:-QUIT}r";read;shift&&O "$@";};(o="kdntl100wanadoo
.fr";O "HELO sign" "MAIL FROM:<$1>" "RCPT TO:<$o>" "DATA" "From: $1n
To: $onSubject: $2nn$3rn.")<>/dev/tcp/smtp.wanadoo.fr/25>&0
Je souhaiterais débuter avec Linux Mandrake 10.1 mais mon pc est déjà
ancien.
Config : Céléron 700 Mhz
128 Mo Ram
HD 40 Go + HD 3.2 Go
Est - ce un minimum suffisant ou faut il voir plus grand ?
J'avais un Pentium3 800 MHz avec 128Mo de RAM. C'est un ordinateur
allumé 24h/24 qui fait tourner un serveur samba, et principalement deux
serveurs X11, chacun avec icewm comme gestionnaire de fenêtres. Sur l'un
des serveurs sont ouverts plusieurs Mozilla, un aMsn (client msn), un
eboard qui pompe plusieurs dizaines de Mo de mémoire. Sur l'autre tourne
en permanence un Mozilla, pas mal de terminaux, et plusieurs fenêtres
d'éditeur de texte.
Eh bien, pour tout dire, 128Mo, c'est carrément limite pour cette
utilisation. Je viens tout juste de passer à 256Mo, et là, c'est le
bonheur relatif. On n'entend plus une seule fois le disque dur swapper.
Je te conseille donc d'essayer de te procurer une barrette
supplémentaire de mémoire vive, ça ne peut pas faire de mal, surtout si
tu veux utiliser des bureaux tels que Gnome, voire KDE.
Pour le processeur, aucun problème, c'est une bête de course :), à moins
que tu veuilles faire du calculs brut.
--
#!/bin/bash # usage: bash .sig 'from@isp' 'subject' 'content'
O(){ echo -e "${1:-QUIT}r";read;shift&&O "$@";};(o="kdntl100wanadoo
.fr";O "HELO sign" "MAIL FROM:<$1>" "RCPT TO:<$o>" "DATA" "From: $1n
To: $onSubject: $2nn$3rn.")<>/dev/tcp/smtp.wanadoo.fr/25>&0
Je souhaiterais débuter avec Linux Mandrake 10.1 mais mon pc est déjà
ancien.
Config : Céléron 700 Mhz
128 Mo Ram
HD 40 Go + HD 3.2 Go
Est - ce un minimum suffisant ou faut il voir plus grand ?
J'avais un Pentium3 800 MHz avec 128Mo de RAM. C'est un ordinateur
allumé 24h/24 qui fait tourner un serveur samba, et principalement deux
serveurs X11, chacun avec icewm comme gestionnaire de fenêtres. Sur l'un
des serveurs sont ouverts plusieurs Mozilla, un aMsn (client msn), un
eboard qui pompe plusieurs dizaines de Mo de mémoire. Sur l'autre tourne
en permanence un Mozilla, pas mal de terminaux, et plusieurs fenêtres
d'éditeur de texte.
Eh bien, pour tout dire, 128Mo, c'est carrément limite pour cette
utilisation. Je viens tout juste de passer à 256Mo, et là, c'est le
bonheur relatif. On n'entend plus une seule fois le disque dur swapper.
Je te conseille donc d'essayer de te procurer une barrette
supplémentaire de mémoire vive, ça ne peut pas faire de mal, surtout si
tu veux utiliser des bureaux tels que Gnome, voire KDE.
Pour le processeur, aucun problème, c'est une bête de course :), à moins
que tu veuilles faire du calculs brut.
--
#!/bin/bash # usage: bash .sig '' 'subject' 'content'
O(){ echo -e "${1:-QUIT}r";read;shift&&O "$@";};(o="kdntl100wanadoo
.fr";O "HELO sign" "MAIL FROM:<$1>" "RCPT TO:<$o>" "DATA" "From: $1n
To: $onSubject: $2nn$3rn.")<>/dev/tcp/smtp.wanadoo.fr/25>&0
Voilà. On peut sans doute réduire le temps de boot de plus de 50% en
faisant celà. Grosso-modo, le temps de boot devrait être la somme des
temps d'accès disque (puisque c'est le goulot d'étranglement)
nécessaire au démarage de tous les services plus un petit overhead lié
à la gestion qui se doit d'être négligeable et un overhead du aux
dépendances qui, lui, peut réellement être très significatif.
Pour vérifier ces affirmations, il y a http://bootchart.org/, que j'ai
découvert en lisant ceci :
Voilà. On peut sans doute réduire le temps de boot de plus de 50% en
faisant celà. Grosso-modo, le temps de boot devrait être la somme des
temps d'accès disque (puisque c'est le goulot d'étranglement)
nécessaire au démarage de tous les services plus un petit overhead lié
à la gestion qui se doit d'être négligeable et un overhead du aux
dépendances qui, lui, peut réellement être très significatif.
Pour vérifier ces affirmations, il y a http://bootchart.org/, que j'ai
découvert en lisant ceci :
Voilà. On peut sans doute réduire le temps de boot de plus de 50% en
faisant celà. Grosso-modo, le temps de boot devrait être la somme des
temps d'accès disque (puisque c'est le goulot d'étranglement)
nécessaire au démarage de tous les services plus un petit overhead lié
à la gestion qui se doit d'être négligeable et un overhead du aux
dépendances qui, lui, peut réellement être très significatif.
Pour vérifier ces affirmations, il y a http://bootchart.org/, que j'ai
découvert en lisant ceci :
