Je me demandais pourquoi ud[1] n'utilise pas crontab, cela
permettrait pourtant d'éviter qu'il utilise de la ram en permanence[2]
sachant qu'il ne fait un check que toutes les 2 minutes[3]... ?
Je me demandais pourquoi ud[1] n'utilise pas crontab, cela
L'invocation d'un programme par cron est assez lourde, le faire toutes les deux minutes serait également coûteux.
À ce point là ?
permettrait pourtant d'éviter qu'il utilise de la ram en permanence[2]
Si tu te soucies de cette question, tu n'utilises pas ud, pour commencer.
Ah non, c'est tellement inutile que c'est devenu indispensable :)
2: 0,2% chez moi sur ma Debian
Comment le mesures-tu ?
avec ps :
$ ps u -p 27506 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s ^^^^ ^^^
-- cLx
Nicolas George
cLx , dans le message <iuhg3k$sfm$, a écrit :
$ ps u -p 27506 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s ^^^^ ^^^
C'est très approximatif, comme mesure, surtout pour une valeur aussi petite. Une bonne partie de cette mémoire est probablement réservée sans être utilisée.
cLx , dans le message <iuhg3k$sfm$1@news.trigofacile.com>, a écrit :
$ ps u -p 27506
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s
^^^^ ^^^
C'est très approximatif, comme mesure, surtout pour une valeur aussi petite.
Une bonne partie de cette mémoire est probablement réservée sans être
utilisée.
$ ps u -p 27506 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s ^^^^ ^^^
C'est très approximatif, comme mesure, surtout pour une valeur aussi petite. Une bonne partie de cette mémoire est probablement réservée sans être utilisée.
Erwan David
cLx 'aimail.com.almost.invalid> écrivait :
Bonjour,
Je me demandais pourquoi ud[1] n'utilise pas crontab, cela permettrait pourtant d'éviter qu'il utilise de la ram en permanence[2] sachant qu'il ne fait un check que toutes les 2 minutes[3]... ?
Merci, cLx
N'oublie pas que 1) cron forke pour invoker le processus, après avoir mis un environnement spécifique, lance en parallèle un processus d'envoi de mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la place...
2) sur un truc comme ça seule une page du code va être en RAM, le reste reste sur le disque,
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Je me demandais pourquoi ud[1] n'utilise pas crontab, cela
permettrait pourtant d'éviter qu'il utilise de la ram en permanence[2]
sachant qu'il ne fait un check que toutes les 2 minutes[3]... ?
Merci,
cLx
N'oublie pas que
1) cron forke pour invoker le processus, après avoir mis un
environnement spécifique, lance en parallèle un processus d'envoi de
mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la
place...
2) sur un truc comme ça seule une page du code va être en RAM, le reste
reste sur le disque,
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Je me demandais pourquoi ud[1] n'utilise pas crontab, cela permettrait pourtant d'éviter qu'il utilise de la ram en permanence[2] sachant qu'il ne fait un check que toutes les 2 minutes[3]... ?
Merci, cLx
N'oublie pas que 1) cron forke pour invoker le processus, après avoir mis un environnement spécifique, lance en parallèle un processus d'envoi de mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la place...
2) sur un truc comme ça seule une page du code va être en RAM, le reste reste sur le disque,
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
cLx
On 30/06/2011 11:41, Nicolas George wrote:
cLx , dans le message <iuhg3k$sfm$, a écrit :
$ ps u -p 27506 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s ^^^^ ^^^
C'est très approximatif, comme mesure, surtout pour une valeur aussi petite. Une bonne partie de cette mémoire est probablement réservée sans être utilisée.
Si cette mémoire est réservée mais non utilisée, peut-elle être utilisé par un autre programme quand même ?
On 30/06/2011 11:41, Nicolas George wrote:
cLx , dans le message <iuhg3k$sfm$1@news.trigofacile.com>, a écrit :
$ ps u -p 27506
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s
^^^^ ^^^
C'est très approximatif, comme mesure, surtout pour une valeur aussi petite.
Une bonne partie de cette mémoire est probablement réservée sans être
utilisée.
Si cette mémoire est réservée mais non utilisée, peut-elle être utilisé par
un autre programme quand même ?
$ ps u -p 27506 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 27506 0.0 0.2 1752 528 ? S<s Jun23 6:22 /usr/bin/ud -s ^^^^ ^^^
C'est très approximatif, comme mesure, surtout pour une valeur aussi petite. Une bonne partie de cette mémoire est probablement réservée sans être utilisée.
Si cette mémoire est réservée mais non utilisée, peut-elle être utilisé par un autre programme quand même ?
cLx
On 30/06/2011 11:52, Erwan David wrote:
N'oublie pas que 1) cron forke pour invoker le processus, après avoir mis un environnement spécifique, lance en parallèle un processus d'envoi de mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la place...
Dans ce cas là des trucs comme inetd n'auraient jamais été écrits ?
Quand tu dis "ça prend de la place", ça la prend où ? En ram temporairement pendant quelques fractions de secondes ? Ou sur le disque ?
2) sur un truc comme ça seule une page du code va être en RAM, le reste reste sur le disque,
Swapper, c'est l'avenir ! ;)
De plus il existe des trucs genre munin qui fonctionnent toutes les 5 minutes pour faire des mesures, et ils sont lancés avec un fichier dans /etc/cron.d/...
On 30/06/2011 11:52, Erwan David wrote:
N'oublie pas que
1) cron forke pour invoker le processus, après avoir mis un
environnement spécifique, lance en parallèle un processus d'envoi de
mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la
place...
Dans ce cas là des trucs comme inetd n'auraient jamais été écrits ?
Quand tu dis "ça prend de la place", ça la prend où ? En ram temporairement
pendant quelques fractions de secondes ? Ou sur le disque ?
2) sur un truc comme ça seule une page du code va être en RAM, le reste
reste sur le disque,
Swapper, c'est l'avenir ! ;)
De plus il existe des trucs genre munin qui fonctionnent toutes les 5 minutes
pour faire des mesures, et ils sont lancés avec un fichier dans /etc/cron.d/...
N'oublie pas que 1) cron forke pour invoker le processus, après avoir mis un environnement spécifique, lance en parallèle un processus d'envoi de mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la place...
Dans ce cas là des trucs comme inetd n'auraient jamais été écrits ?
Quand tu dis "ça prend de la place", ça la prend où ? En ram temporairement pendant quelques fractions de secondes ? Ou sur le disque ?
2) sur un truc comme ça seule une page du code va être en RAM, le reste reste sur le disque,
Swapper, c'est l'avenir ! ;)
De plus il existe des trucs genre munin qui fonctionnent toutes les 5 minutes pour faire des mesures, et ils sont lancés avec un fichier dans /etc/cron.d/...
Nicolas George
cLx , dans le message <iuhv7b$d4v$, a écrit :
Si cette mémoire est réservée mais non utilisée, peut-elle être utilisé par un autre programme quand même ?
Avec la configuration par défaut, oui.
cLx , dans le message <iuhv7b$d4v$1@news.trigofacile.com>, a écrit :
Si cette mémoire est réservée mais non utilisée, peut-elle être utilisé par
un autre programme quand même ?
Si cette mémoire est réservée mais non utilisée, peut-elle être utilisé par un autre programme quand même ?
Avec la configuration par défaut, oui.
Erwan David
cLx 'aimail.com.almost.invalid> écrivait :
On 30/06/2011 11:52, Erwan David wrote:
N'oublie pas que 1) cron forke pour invoker le processus, après avoir mis un environnement spécifique, lance en parallèle un processus d'envoi de mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la place...
Dans ce cas là des trucs comme inetd n'auraient jamais été écrits ?
inetd c'est pour des services lancés très peu souvent, si tu as un service utilisé souvent (et une fois toutes les 2 minutes, c'est souvent), tu fais un démon...
Quand tu dis "ça prend de la place", ça la prend où ? En ram temporairement pendant quelques fractions de secondes ? Ou sur le disque ?
RAM, CPU et IOs...
2) sur un truc comme ça seule une page du code va être en RAM, le reste reste sur le disque,
Swapper, c'est l'avenir ! ;)
C'est pas du swap : le code *est* sur le disque inutile de charger tout le code en RAM, surtout quand tu es dans une boucle...
De plus il existe des trucs genre munin qui fonctionnent toutes les 5 minutes pour faire des mesures, et ils sont lancés avec un fichier dans /etc/cron.d/...
Oui, et ? après on peut vouloir un peu plus optimiser les choses (perso ma limite est à 1 fois toutes les 5 minutes justement).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
N'oublie pas que
1) cron forke pour invoker le processus, après avoir mis un
environnement spécifique, lance en parallèle un processus d'envoi de
mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la
place...
Dans ce cas là des trucs comme inetd n'auraient jamais été écrits ?
inetd c'est pour des services lancés très peu souvent, si tu as un
service utilisé souvent (et une fois toutes les 2 minutes, c'est
souvent), tu fais un démon...
Quand tu dis "ça prend de la place", ça la prend où ? En ram temporairement
pendant quelques fractions de secondes ? Ou sur le disque ?
RAM, CPU et IOs...
2) sur un truc comme ça seule une page du code va être en RAM, le reste
reste sur le disque,
Swapper, c'est l'avenir ! ;)
C'est pas du swap : le code *est* sur le disque inutile de charger tout
le code en RAM, surtout quand tu es dans une boucle...
De plus il existe des trucs genre munin qui fonctionnent toutes les 5 minutes
pour faire des mesures, et ils sont lancés avec un fichier dans /etc/cron.d/...
Oui, et ? après on peut vouloir un peu plus optimiser les choses (perso
ma limite est à 1 fois toutes les 5 minutes justement).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
N'oublie pas que 1) cron forke pour invoker le processus, après avoir mis un environnement spécifique, lance en parallèle un processus d'envoi de mail qui récupère la sortie standard, etc. C'est lourd et ça prend de la place...
Dans ce cas là des trucs comme inetd n'auraient jamais été écrits ?
inetd c'est pour des services lancés très peu souvent, si tu as un service utilisé souvent (et une fois toutes les 2 minutes, c'est souvent), tu fais un démon...
Quand tu dis "ça prend de la place", ça la prend où ? En ram temporairement pendant quelques fractions de secondes ? Ou sur le disque ?
RAM, CPU et IOs...
2) sur un truc comme ça seule une page du code va être en RAM, le reste reste sur le disque,
Swapper, c'est l'avenir ! ;)
C'est pas du swap : le code *est* sur le disque inutile de charger tout le code en RAM, surtout quand tu es dans une boucle...
De plus il existe des trucs genre munin qui fonctionnent toutes les 5 minutes pour faire des mesures, et ils sont lancés avec un fichier dans /etc/cron.d/...
Oui, et ? après on peut vouloir un peu plus optimiser les choses (perso ma limite est à 1 fois toutes les 5 minutes justement).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Yliur
Le 30 Jun 2011 14:16:33 GMT Nicolas George <nicolas$ a écrit :
cLx , dans le message <iuhv7b$d4v$, a écrit : > Si cette mémoire est réservée mais non utilisée, peut-elle être > utilisé par un autre programme quand même ?
Avec la configuration par défaut, oui.
Quelques questions sur le sujet : - Comment les programmes peuvent-ils réserver de la mémoire ? - A quoi cela sert-il ?
Le 30 Jun 2011 14:16:33 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :
cLx , dans le message <iuhv7b$d4v$1@news.trigofacile.com>, a écrit :
> Si cette mémoire est réservée mais non utilisée, peut-elle être
> utilisé par un autre programme quand même ?
Avec la configuration par défaut, oui.
Quelques questions sur le sujet :
- Comment les programmes peuvent-ils réserver de la mémoire ?
- A quoi cela sert-il ?
Le 30 Jun 2011 14:16:33 GMT Nicolas George <nicolas$ a écrit :
cLx , dans le message <iuhv7b$d4v$, a écrit : > Si cette mémoire est réservée mais non utilisée, peut-elle être > utilisé par un autre programme quand même ?
Avec la configuration par défaut, oui.
Quelques questions sur le sujet : - Comment les programmes peuvent-ils réserver de la mémoire ? - A quoi cela sert-il ?
Nicolas George
Yliur , dans le message , a écrit :
- Comment les programmes peuvent-ils réserver de la mémoire ?
brk/sbrk et mmap.
- A quoi cela sert-il ?
À en avoir, quelle question !
Yliur , dans le message <20110630182850.54d73d5c@alcheringa>, a écrit :
- Comment les programmes peuvent-ils réserver de la mémoire ?
