Les developpeurs sont conscients de ce trop grznd besoin de ressources et travaillent dessus :-), ils le disent...
Cependant, j'ai bien l'impression que tout ce qui est CMS, et plus généralement programmation web, est encore plus un nid à incompétence que le reste de l'informatique. Il n'y a qu'à voir le succès de PHP pour s'en convaincre.
R12y wrote in message <pan.2005.03.14.14.27.20.120907@mail.rktmb.org>:
Les developpeurs sont conscients de ce trop grznd
besoin de ressources et travaillent dessus :-), ils le disent...
Cependant, j'ai bien l'impression que tout ce qui est CMS, et plus
généralement programmation web, est encore plus un nid à incompétence que le
reste de l'informatique. Il n'y a qu'à voir le succès de PHP pour s'en
convaincre.
Les developpeurs sont conscients de ce trop grznd besoin de ressources et travaillent dessus :-), ils le disent...
Cependant, j'ai bien l'impression que tout ce qui est CMS, et plus généralement programmation web, est encore plus un nid à incompétence que le reste de l'informatique. Il n'y a qu'à voir le succès de PHP pour s'en convaincre.
Rakotomandimby (R12y) Mihamina
( Mon, 14 Mar 2005 14:55:34 +0000 ) Nicolas George :
Il n'y a qu'à voir le succès de PHP pour s'en convaincre.
:-)
oui mais ça c'est parcequ'on a fait croire aux gens que l'informatique est accessible, que l'on peut faire des "choses" sans rian avoir appris. je trouve que quelquepart, c'est tant mieux: ça permet de stratifier (les bons d'un coté et les moins bon de l'autre). si tout le monde était "bon" et compétent, on aurait du mal...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 14:55:34 +0000 ) Nicolas George :
Il n'y a qu'à voir le succès de PHP pour s'en
convaincre.
:-)
oui mais ça c'est parcequ'on a fait croire aux gens que l'informatique
est accessible, que l'on peut faire des "choses" sans rian avoir appris.
je trouve que quelquepart, c'est tant mieux: ça permet de stratifier (les
bons d'un coté et les moins bon de l'autre). si tout le monde était
"bon" et compétent, on aurait du mal...
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Mon, 14 Mar 2005 14:55:34 +0000 ) Nicolas George :
Il n'y a qu'à voir le succès de PHP pour s'en convaincre.
:-)
oui mais ça c'est parcequ'on a fait croire aux gens que l'informatique est accessible, que l'on peut faire des "choses" sans rian avoir appris. je trouve que quelquepart, c'est tant mieux: ça permet de stratifier (les bons d'un coté et les moins bon de l'autre). si tout le monde était "bon" et compétent, on aurait du mal...
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Matthieu Moy
Jerome Lambert writes:
Quand un programme demande de la mémoire et qu'il n'y a plus de mémoire vive disponible, le système identifie les processus n'ayant pas été "réveillés" depuis un certain temps et les envoie dans le swap, libérant alors de la mémoire vive.
Pas tout a fait: Linux fait du "swap" par page de mémoire et non par processus, donc, si tu passes d'un logiciel a l'autre sans arrêt, mais en n'utilisant qu'une partie de la mémoire de ton logiciel, ton système peut mettre le reste en swap sans pénaliser les perfs.
-- Matthieu
Jerome Lambert <jerome.lambert@swing.be> writes:
Quand un programme demande de la mémoire et qu'il n'y a plus de
mémoire vive disponible, le système identifie les processus n'ayant
pas été "réveillés" depuis un certain temps et les envoie dans le
swap, libérant alors de la mémoire vive.
Pas tout a fait: Linux fait du "swap" par page de mémoire et non par
processus, donc, si tu passes d'un logiciel a l'autre sans arrêt, mais
en n'utilisant qu'une partie de la mémoire de ton logiciel, ton
système peut mettre le reste en swap sans pénaliser les perfs.
Quand un programme demande de la mémoire et qu'il n'y a plus de mémoire vive disponible, le système identifie les processus n'ayant pas été "réveillés" depuis un certain temps et les envoie dans le swap, libérant alors de la mémoire vive.
Pas tout a fait: Linux fait du "swap" par page de mémoire et non par processus, donc, si tu passes d'un logiciel a l'autre sans arrêt, mais en n'utilisant qu'une partie de la mémoire de ton logiciel, ton système peut mettre le reste en swap sans pénaliser les perfs.
-- Matthieu
Matthieu Moy
l'indien writes:
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il est mal fait.
while (1) { if (user_request()) { process_user_request(); } }
? ;-)
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser une page mémoire de code (la boucle qui fait le select sur la socket de connection) et une page mémoire de donnée (qui contient le fd correspondant à cette même socket) et quasiment aucun CPU (en tout cas, de façon indétectable par l'utilisateur).
Ceci dit, ça prends du temps au boot, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap. Négligeable sur une station allumée 24h sur 24, mais ch***t pour une machine qu'on ne démarre que sur demande (genre le PC a coté de mon lit ;-).
(et pis bon, coté sécurité, c'est moyen moyen de laisser tourner des daemons si c'est pour pas s'en servir)
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il
est mal fait.
while (1) {
if (user_request()) {
process_user_request();
}
}
? ;-)
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser
une page mémoire de code (la boucle qui fait le select sur la socket de
connection) et une page mémoire de donnée (qui contient le fd
correspondant à cette même socket) et quasiment aucun CPU (en tout cas,
de façon indétectable par l'utilisateur).
Ceci dit, ça prends du temps au boot, et ça ralenti un peu la machine
le temps qu'elle mette tout ça en swap. Négligeable sur une station
allumée 24h sur 24, mais ch***t pour une machine qu'on ne démarre que
sur demande (genre le PC a coté de mon lit ;-).
(et pis bon, coté sécurité, c'est moyen moyen de laisser tourner des
daemons si c'est pour pas s'en servir)
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il est mal fait.
while (1) { if (user_request()) { process_user_request(); } }
? ;-)
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser une page mémoire de code (la boucle qui fait le select sur la socket de connection) et une page mémoire de donnée (qui contient le fd correspondant à cette même socket) et quasiment aucun CPU (en tout cas, de façon indétectable par l'utilisateur).
Ceci dit, ça prends du temps au boot, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap. Négligeable sur une station allumée 24h sur 24, mais ch***t pour une machine qu'on ne démarre que sur demande (genre le PC a coté de mon lit ;-).
(et pis bon, coté sécurité, c'est moyen moyen de laisser tourner des daemons si c'est pour pas s'en servir)
-- Matthieu
l'indien
On Mon, 14 Mar 2005 23:03:42 +0100, Matthieu Moy wrote:
l'indien writes:
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il est mal fait.
while (1) { if (user_request()) { process_user_request(); } }
? ;-)
Voilà... Sauf qu'il vaut mieux faire un sleep, si on ne veut pas bouffer tout le CPU ;-)
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser une page mémoire de code (la boucle qui fait le select sur la socket de connection) et une page mémoire de donnée (qui contient le fd correspondant à cette même socket) et quasiment aucun CPU (en tout cas, de façon indétectable par l'utilisateur).
Ceci dit, ça prends du temps au boot
Ah non ! Un serveur bien fait, son main, c'est: int main (...) { if (fork() == 0) { daemonize(); real_main(); }
return 0; }
Si ça augmente le temps de boot, il est temps de remplacer ton 286 !
, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour garder sa config. Ca n'est pas une bonne excuse.
[...]
(et pis bon, coté sécurité, c'est moyen moyen de laisser tourner des daemons si c'est pour pas s'en servir)
Ah, ça OK, c'est _le_ bon argument, à mon avis.
On Mon, 14 Mar 2005 23:03:42 +0100, Matthieu Moy wrote:
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il
est mal fait.
while (1) {
if (user_request()) {
process_user_request();
}
}
? ;-)
Voilà... Sauf qu'il vaut mieux faire un sleep, si on ne veut pas bouffer
tout le CPU ;-)
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser
une page mémoire de code (la boucle qui fait le select sur la socket de
connection) et une page mémoire de donnée (qui contient le fd
correspondant à cette même socket) et quasiment aucun CPU (en tout cas,
de façon indétectable par l'utilisateur).
Ceci dit, ça prends du temps au boot
Ah non !
Un serveur bien fait, son main, c'est:
int main (...)
{
if (fork() == 0) {
daemonize();
real_main();
}
return 0;
}
Si ça augmente le temps de boot, il est temps de remplacer ton 286 !
, et ça ralenti un peu la machine
le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé
utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour
garder sa config. Ca n'est pas une bonne excuse.
[...]
(et pis bon, coté sécurité, c'est moyen moyen de laisser tourner des
daemons si c'est pour pas s'en servir)
On Mon, 14 Mar 2005 23:03:42 +0100, Matthieu Moy wrote:
l'indien writes:
Si il consome des ressources quand personne ne s'y connecte, c'est qu'il est mal fait.
while (1) { if (user_request()) { process_user_request(); } }
? ;-)
Voilà... Sauf qu'il vaut mieux faire un sleep, si on ne veut pas bouffer tout le CPU ;-)
Un daemon sur lequel on ne se connecte pas devrait tout au plus utiliser une page mémoire de code (la boucle qui fait le select sur la socket de connection) et une page mémoire de donnée (qui contient le fd correspondant à cette même socket) et quasiment aucun CPU (en tout cas, de façon indétectable par l'utilisateur).
Ceci dit, ça prends du temps au boot
Ah non ! Un serveur bien fait, son main, c'est: int main (...) { if (fork() == 0) { daemonize(); real_main(); }
return 0; }
Si ça augmente le temps de boot, il est temps de remplacer ton 286 !
, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour garder sa config. Ca n'est pas une bonne excuse.
[...]
(et pis bon, coté sécurité, c'est moyen moyen de laisser tourner des daemons si c'est pour pas s'en servir)
Ah, ça OK, c'est _le_ bon argument, à mon avis.
Khanh-Dang
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.
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.
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.
Le boot de ma machine, sur laquelle je n'ai pourtant pas installé tant de choses que ça, c'est un peu de boot du noyau, et ensuite "starting machin", "starting bidule", ... pour la plupart, c'est assez court, mais multiplié par le nombre de trucs a lancer, ça finit par faire quelques dizaines de secondes.
, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour garder sa config. Ca n'est pas une bonne excuse.
Et le code executable de ton démon, il est pas chargé en RAM ?
Si je regarde les processus qui bouffent de la RAM sur ma machine actuellement, sur les 20 plus gros bouffeurs de RAM, il y a gconfd, cupsd, exim et xprint, sachant que depuis le boot, je n'ai rien imprimé, pas utilisé exim, et pour gconf, je ne sais même pas pourquoi il est lancé.
Ça reste dans les limites du raisonnable sur la somme, mais ça n'est pas une raison pour gaspiller.
Le boot de ma machine, sur laquelle je n'ai pourtant pas installé tant
de choses que ça, c'est un peu de boot du noyau, et ensuite "starting
machin", "starting bidule", ... pour la plupart, c'est assez court,
mais multiplié par le nombre de trucs a lancer, ça finit par faire
quelques dizaines de secondes.
, et ça ralenti un peu la machine
le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé
utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour
garder sa config. Ca n'est pas une bonne excuse.
Et le code executable de ton démon, il est pas chargé en RAM ?
Si je regarde les processus qui bouffent de la RAM sur ma machine
actuellement, sur les 20 plus gros bouffeurs de RAM, il y a gconfd,
cupsd, exim et xprint, sachant que depuis le boot, je n'ai rien
imprimé, pas utilisé exim, et pour gconf, je ne sais même pas pourquoi
il est lancé.
Ça reste dans les limites du raisonnable sur la somme, mais ça n'est
pas une raison pour gaspiller.
Le boot de ma machine, sur laquelle je n'ai pourtant pas installé tant de choses que ça, c'est un peu de boot du noyau, et ensuite "starting machin", "starting bidule", ... pour la plupart, c'est assez court, mais multiplié par le nombre de trucs a lancer, ça finit par faire quelques dizaines de secondes.
, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour garder sa config. Ca n'est pas une bonne excuse.
Et le code executable de ton démon, il est pas chargé en RAM ?
Si je regarde les processus qui bouffent de la RAM sur ma machine actuellement, sur les 20 plus gros bouffeurs de RAM, il y a gconfd, cupsd, exim et xprint, sachant que depuis le boot, je n'ai rien imprimé, pas utilisé exim, et pour gconf, je ne sais même pas pourquoi il est lancé.
Ça reste dans les limites du raisonnable sur la somme, mais ça n'est pas une raison pour gaspiller.
-- Matthieu
Khanh-Dang
et pour gconf, je ne sais même pas pourquoi il est lancé.
Chez moi aussi, gconf est lancé alors que je n'utilise pas gnome. Par contre, je sais que c'est à cause de mon Mozilla que j'ai compilé avec gtk2. En compilant avec le support de gtk (version 1) mais sans gtk2, je n'ai plus de gconfd qui se lance tout seul.
et pour gconf, je ne sais même pas pourquoi
il est lancé.
Chez moi aussi, gconf est lancé alors que je n'utilise pas gnome. Par
contre, je sais que c'est à cause de mon Mozilla que j'ai compilé avec
gtk2. En compilant avec le support de gtk (version 1) mais sans gtk2, je
n'ai plus de gconfd qui se lance tout seul.
et pour gconf, je ne sais même pas pourquoi il est lancé.
Chez moi aussi, gconf est lancé alors que je n'utilise pas gnome. Par contre, je sais que c'est à cause de mon Mozilla que j'ai compilé avec gtk2. En compilant avec le support de gtk (version 1) mais sans gtk2, je n'ai plus de gconfd qui se lance tout seul.
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.
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
On Tue, 15 Mar 2005 01:14:43 +0100, Matthieu Moy wrote:
l'indien writes:
Ceci dit, ça prends du temps au boot
Ah non !
Le boot de ma machine, sur laquelle je n'ai pourtant pas installé tant de choses que ça, c'est un peu de boot du noyau, et ensuite "starting machin", "starting bidule", ... pour la plupart, c'est assez court, mais multiplié par le nombre de trucs a lancer, ça finit par faire quelques dizaines de secondes.
Sur un PPC 200 Mhz, j'ai la main dans un shell en 1.9 s. Si le fait de démarer des process en plus amène ce temps à plus de 30 secondes, il y a clairement un problème. Sur mon Athlon 64, j'arrive dans gdm en moins de 15 secondes (depuis lilo), en comptant les probes SCSI (qui sont longs...). Le plus long, c'est de démarer gnome ! Et là, j'ai des serveurs qui tournent... Encore une fois, je peux admettre que le temps soit multiplié par deux dans certains cas particuliers, mais plus d'une minutes, ça m'inciterait à changer sérieusement me pencher sur les logiciels que j'utilise.
, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour garder sa config. Ca n'est pas une bonne excuse.
Et le code executable de ton démon, il est pas chargé en RAM ?
Non. Seul le code effectivement utilisé est chargé en RAM.
Si je regarde les processus qui bouffent de la RAM sur ma machine actuellement, sur les 20 plus gros bouffeurs de RAM, il y a gconfd, cupsd, exim et xprint, sachant que depuis le boot, je n'ai rien imprimé, pas utilisé exim, et pour gconf, je ne sais même pas pourquoi il est lancé.
Attention, il faut regarder la taille résident en RAM (le champ RSS), pas la taille totale ! Si je fait un executable de 500 Mo qui n'execute qu'une seule page de code, sa taille totale sera 500 Mo mais sa taille résidente sera de 4 Ko. De même, si ce programme mappe à titre préventif 500 autres Mo de RAM virtuelle mais ne les utilise pas, sa taille deviendra 1 Go mais il ne consomera pas plus de RAM pour autant.
[...]
On Tue, 15 Mar 2005 01:14:43 +0100, Matthieu Moy wrote:
Le boot de ma machine, sur laquelle je n'ai pourtant pas installé tant
de choses que ça, c'est un peu de boot du noyau, et ensuite "starting
machin", "starting bidule", ... pour la plupart, c'est assez court,
mais multiplié par le nombre de trucs a lancer, ça finit par faire
quelques dizaines de secondes.
Sur un PPC 200 Mhz, j'ai la main dans un shell en 1.9 s.
Si le fait de démarer des process en plus amène ce temps à plus de 30
secondes, il y a clairement un problème.
Sur mon Athlon 64, j'arrive dans gdm en moins de 15 secondes (depuis
lilo), en comptant les probes SCSI (qui sont longs...). Le plus long,
c'est de démarer gnome !
Et là, j'ai des serveurs qui tournent...
Encore une fois, je peux admettre que le temps soit multiplié par deux
dans certains cas particuliers, mais plus d'une minutes, ça m'inciterait
à changer sérieusement me pencher sur les logiciels que j'utilise.
, et ça ralenti un peu la machine
le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé
utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour
garder sa config. Ca n'est pas une bonne excuse.
Et le code executable de ton démon, il est pas chargé en RAM ?
Non. Seul le code effectivement utilisé est chargé en RAM.
Si je regarde les processus qui bouffent de la RAM sur ma machine
actuellement, sur les 20 plus gros bouffeurs de RAM, il y a gconfd,
cupsd, exim et xprint, sachant que depuis le boot, je n'ai rien
imprimé, pas utilisé exim, et pour gconf, je ne sais même pas pourquoi
il est lancé.
Attention, il faut regarder la taille résident en RAM (le champ RSS), pas
la taille totale !
Si je fait un executable de 500 Mo qui n'execute qu'une seule page de
code, sa taille totale sera 500 Mo mais sa taille résidente sera de 4
Ko. De même, si ce programme mappe à titre préventif 500 autres Mo de
RAM virtuelle mais ne les utilise pas, sa taille deviendra 1 Go mais il ne
consomera pas plus de RAM pour autant.
On Tue, 15 Mar 2005 01:14:43 +0100, Matthieu Moy wrote:
l'indien writes:
Ceci dit, ça prends du temps au boot
Ah non !
Le boot de ma machine, sur laquelle je n'ai pourtant pas installé tant de choses que ça, c'est un peu de boot du noyau, et ensuite "starting machin", "starting bidule", ... pour la plupart, c'est assez court, mais multiplié par le nombre de trucs a lancer, ça finit par faire quelques dizaines de secondes.
Sur un PPC 200 Mhz, j'ai la main dans un shell en 1.9 s. Si le fait de démarer des process en plus amène ce temps à plus de 30 secondes, il y a clairement un problème. Sur mon Athlon 64, j'arrive dans gdm en moins de 15 secondes (depuis lilo), en comptant les probes SCSI (qui sont longs...). Le plus long, c'est de démarer gnome ! Et là, j'ai des serveurs qui tournent... Encore une fois, je peux admettre que le temps soit multiplié par deux dans certains cas particuliers, mais plus d'une minutes, ça m'inciterait à changer sérieusement me pencher sur les logiciels que j'utilise.
, et ça ralenti un peu la machine le temps qu'elle mette tout ça en swap.
Encore une fois non. Si le serveur n'a jamais de requête, il est censé utiliser une quantité de mémoire négligeable, juste ce qu'il faut pour garder sa config. Ca n'est pas une bonne excuse.
Et le code executable de ton démon, il est pas chargé en RAM ?
Non. Seul le code effectivement utilisé est chargé en RAM.
Si je regarde les processus qui bouffent de la RAM sur ma machine actuellement, sur les 20 plus gros bouffeurs de RAM, il y a gconfd, cupsd, exim et xprint, sachant que depuis le boot, je n'ai rien imprimé, pas utilisé exim, et pour gconf, je ne sais même pas pourquoi il est lancé.
Attention, il faut regarder la taille résident en RAM (le champ RSS), pas la taille totale ! Si je fait un executable de 500 Mo qui n'execute qu'une seule page de code, sa taille totale sera 500 Mo mais sa taille résidente sera de 4 Ko. De même, si ce programme mappe à titre préventif 500 autres Mo de RAM virtuelle mais ne les utilise pas, sa taille deviendra 1 Go mais il ne consomera pas plus de RAM pour autant.
