Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Dans sa configuration par défaut at ne permet de lancer des tâches qu'avec une granularité de l'ordre de la minute. atd accepte toutefois comme argument une option (-b) qui semble pouvoir augmenter cette granularité, elle semble pourtant sans effet chez moi:
root@peeranha3:/home/geb# ps aux | grep atd daemon 4787 0.0 0.0 2212 496 ? Ss 16:48 0:00 /usr/sbin/atd -l 50 -b 5 geb@peeranha3:~$ echo 'date' | at -t 05101747.24 warning: commands will be executed using /bin/sh job 41 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.32 warning: commands will be executed using /bin/sh job 42 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.47 warning: commands will be executed using /bin/sh job 43 at Thu May 10 17:47:00 2012
Les commandes sont toujours exécutées avec une granularité de l'ordre de la minute. Le problème est identique lorsque j'essai d'augmenter le délai à 300 secondes (pour tester), mes commandes sont toujours exécutées avec une précision de l'ordre de la minute. J'utilise la version de at de debian stable (squeeze): 3.1.12-1.
Auriez vous une idée ? Je m'y prend mal ? Auriez vous une solution de remplacement simple à proposer ? Je suppose que certains systèmes de gestion de batch permettent une meilleure granularité, mais je suis un peu effrayé par la complexité de ceux ci.
D'avance, merci pour vos avis etc,
Cdlt,
Bonsoir,
ce n'est pas l'argument -b qu'il faut utiliser mais -t voici une copie du man ….
-b Is an alias for batch. -t Specify the job time using the POSIX time format. The argument should be in the form [[CC]YY]MMDDhhmm[.SS] where each pair of letters represents the following:
CC The first two digits of the year (the century). YY The second two digits of the year. MM The month of the year, from 1 to 12. DD the day of the month, from 1 to 31. hh The hour of the day, from 0 to 23. mm The minute of the hour, from 0 to 59. SS The second of the minute, from 0 to 61.
If the CC and YY letter pairs are not specified, the values default to the current year. If the SS letter pair is not speci- fied, the value defaults to 0.
Le 10 mai 2012 à 18:11, Mathieu Goessens a écrit :
Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Dans sa configuration par défaut at ne permet de lancer des tâches qu'avec une granularité de l'ordre de la minute. atd accepte toutefois comme argument une option (-b) qui semble pouvoir augmenter cette granularité, elle semble pourtant sans effet chez moi:
root@peeranha3:/home/geb# ps aux | grep atd daemon 4787 0.0 0.0 2212 496 ? Ss 16:48 0:00 /usr/sbin/atd -l 50 -b 5 geb@peeranha3:~$ echo 'date' | at -t 05101747.24 warning: commands will be executed using /bin/sh job 41 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.32 warning: commands will be executed using /bin/sh job 42 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.47 warning: commands will be executed using /bin/sh job 43 at Thu May 10 17:47:00 2012
Les commandes sont toujours exécutées avec une granularité de l'ordre de la minute. Le problème est identique lorsque j'essai d'augmenter le délai à 300 secondes (pour tester), mes commandes sont toujours exécutées avec une précision de l'ordre de la minute. J'utilise la version de at de debian stable (squeeze): 3.1.12-1.
Auriez vous une idée ? Je m'y prend mal ? Auriez vous une solution de remplacement simple à proposer ? Je suppose que certains systèmes de gestion de batch permettent une meilleure granularité, mais je suis un peu effrayé par la complexité de ceux ci.
D'avance, merci pour vos avis etc,
Cdlt,
-- Mathieu Goessens IT consultant. gebura@poolp.org
- 33 6 07 91 54 87
http://gebura.eu.org _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
Merci, mais c'est bien ce que je fais :)
geb@peeranha3:~$ echo 'date' | at -t 05101747.24 warning: commands will be executed using /bin/sh job 41 at Thu May 10 17:47:00 2012
=> Le moment où exécuter cette commande est arrondi à la minute.
Il semble que le deamon, puisse être réglé avec cette option ( -b) mais, celle ci semble ignorée, que l'on cherche à réduire l'intervalle comme à l'augmenter.
Par contre, atd, le daemon accepte bien cet argument
Le 2012-05-10 19:53, fouadlist a écrit :
Bonsoir,
ce n'est pas l'argument -b qu'il faut utiliser mais -t voici une copie du man ….
-b Is an alias for batch. -t Specify the job time using the POSIX time format. The argument should be in the form [[CC]YY]MMDDhhmm[.SS] where each pair of letters represents the following:
CC The first two digits of the year (thecentury). YY The second two digits of the year. MM The month of the year, from 1 to 12. DD the day of the month, from 1 to 31. hh The hour of the day, from 0 to 23. mm The minute of the hour, from 0 to 59. SS The second of the minute, from 0 to 61.
If the CC and YY letter pairs are not specified, thevalues default to the current year. If the SS letter pair is not speci- fied, the value defaults to 0.
Le 10 mai 2012 à 18:11, Mathieu Goessens a écrit :
Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Dans sa configuration par défaut at ne permet de lancer des tâches qu'avec une granularité de l'ordre de la minute. atd accepte toutefois comme argument une option (-b) qui semble pouvoir augmenter cette granularité, elle semble pourtant sans effet chez moi:
root@peeranha3:/home/geb# ps aux | grep atd daemon 4787 0.0 0.0 2212 496 ? Ss 16:48 0:00 /usr/sbin/atd -l 50 -b 5 geb@peeranha3:~$ echo 'date' | at -t 05101747.24 warning: commands will be executed using /bin/sh job 41 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.32 warning: commands will be executed using /bin/sh job 42 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.47 warning: commands will be executed using /bin/sh job 43 at Thu May 10 17:47:00 2012
Les commandes sont toujours exécutées avec une granularité de l'ordre de la minute. Le problème est identique lorsque j'essai d'augmenter le délai à 300 secondes (pour tester), mes commandes sont toujours exécutées avec une précision de l'ordre de la minute. J'utilise la version de at de debian stable (squeeze): 3.1.12-1.
Auriez vous une idée ? Je m'y prend mal ? Auriez vous une solution de remplacement simple à proposer ? Je suppose que certains systèmes de gestion de batch permettent une meilleure granularité, mais je suis un peu effrayé par la complexité de ceux ci.
D'avance, merci pour vos avis etc,
Cdlt,
-- Mathieu Goessens IT consultant. gebura@poolp.org
- 33 6 07 91 54 87
http://gebura.eu.org _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
Le 10 mai 2012 20:16, Mathieu Goessens gebura@poolp.org a écrit :
Il semble que le deamon, puisse être réglé avec cette option ( -b) mais, celle ci semble ignorée, que l'on cherche à réduire l'intervalle comme à l'augmenter.
OK mais le script d'init de Debian ne gère pas les options du daemon, de plus cette option prends un argument.
Mais je viens d'essayer et ça ne marche pas mieux...
Solution alternative qui marche : echo '{ sleep 23; date; }' | at -t 05102054 -m
Greg
Par contre, atd, le daemon accepte bien cet argument
Le 2012-05-10 19:53, fouadlist a écrit :
Bonsoir,
ce n'est pas l'argument -b qu'il faut utiliser mais -t voici une copie du man ….
-b Is an alias for batch. -t Specify the job time using the POSIX time format. The argument should be in the form [[CC]YY]MMDDhhmm[.SS] where each pair of letters represents the following:
CC The first two digits of the year (the century). YY The second two digits of the year. MM The month of the year, from 1 to 12. DD the day of the month, from 1 to 31. hh The hour of the day, from 0 to 23. mm The minute of the hour, from 0 to 59. SS The second of the minute, from 0 to 61. If the CC and YY letter pairs are not specified, the values default to the current year. If the SS letter pair isnot speci- fied, the value defaults to 0.
Le 10 mai 2012 à 18:11, Mathieu Goessens a écrit :
Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Dans sa configuration par défaut at ne permet de lancer des tâches qu'avec une granularité de l'ordre de la minute. atd accepte toutefois comme argument une option (-b) qui semble pouvoir augmenter cette granularité, elle semble pourtant sans effet chez moi:
root@peeranha3:/home/geb# ps aux | grep atd daemon 4787 0.0 0.0 2212 496 ? Ss 16:48 0:00 /usr/sbin/atd -l 50 -b 5 geb@peeranha3:~$ echo 'date' | at -t 05101747.24 warning: commands will be executed using /bin/sh job 41 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.32 warning: commands will be executed using /bin/sh job 42 at Thu May 10 17:47:00 2012 geb@peeranha3:~$ echo 'date' | at -t 05101747.47 warning: commands will be executed using /bin/sh job 43 at Thu May 10 17:47:00 2012
Les commandes sont toujours exécutées avec une granularité de l'ordre de la minute. Le problème est identique lorsque j'essai d'augmenter le délai à 300 secondes (pour tester), mes commandes sont toujours exécutées avec une précision de l'ordre de la minute. J'utilise la version de at de debian stable (squeeze): 3.1.12-1.
Auriez vous une idée ? Je m'y prend mal ? Auriez vous une solution de remplacement simple à proposer ? Je suppose que certains systèmes de gestion de batch permettent une meilleure granularité, mais je suis un peu effrayé par la complexité de ceux ci.
D'avance, merci pour vos avis etc,
Cdlt,
-- Mathieu Goessens IT consultant. gebura@poolp.org
- 33 6 07 91 54 87
http://gebura.eu.org ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Mathieu Goessens IT consultant. gebura@poolp.org
- 33 6 07 91 54 87
http://gebura.eu.org ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/05/2012 18:11, Mathieu Goessens a écrit :
Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Tu peux nous expliquer un peu plus ce que tu souhaites faire véritablement ? Peut-être existe-t-il une autre solution que celle que tu cherches à suivre à tout prix...
Cordialement,
/JYL
Le 2012-05-10 20:42, Jean-Yves LENHOF a écrit :
Le 10/05/2012 18:11, Mathieu Goessens a écrit :
Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Tu peux nous expliquer un peu plus ce que tu souhaites faire véritablement ? Peut-être existe-t-il une autre solution que celle que tu cherches à suivre à tout prix...
J'ai une série de logs web (plus précisément de logs de proxy au format squid), que je souhaites rejouer (pour tester les performances d'un proxy-cache distribué sur lequel je travail).
Je pensais simplement programmer un curl avec at pour chaque ligne de log (et conserver donc les écarts entre les accès). Si il existe une autre solution pour rejouer ces logs, ou simplement une solution de remplacement à at, je suis évidement preneur :)
2012/5/10 Mathieu Goessens gebura@poolp.org
J'ai une série de logs web (plus précisément de logs de proxy au format squid), que je souhaites rejouer (pour tester les performances d'un proxy-cache distribué sur lequel je travail).
Je pensais simplement programmer un curl avec at pour chaque ligne de log (et conserver donc les écarts entre les accès). Si il existe une autre solution pour rejouer ces logs, ou simplement une solution de remplacement à at, je suis évidement preneur :)
Bonjour,
Je serais un peu de l'avis de http://serverfault.com/questions/84041/how-can-i-replay-apache-access-logs-b..., quelques lignes de script dans un langage quelconque devraient être suffisantes.
Une solution un peu cochonne serait d'avoir un script qui lit la prochaine date, qui sleep (now() - date_prochaine_ligne) et qui spawn ton simulateur de requête (curl) en background. De cette manière, tu peux meme lancer plusieurs "clients" virtuels, qui vont chacun rejouer ton log.
Evidemment, si tu arrives à faire marcher un JMeter (en passant tes logs au awk), c'est encore plus paramétrable (mais probablement plus long que les quelques lignes de script en question).
Cordialement,
Le 10/05/12 20:49, Mathieu Goessens a écrit :
J'ai une série de logs web (plus précisément de logs de proxy au format squid), que je souhaites rejouer (pour tester les performances d'un proxy-cache distribué sur lequel je travail).
Je pensais simplement programmer un curl avec at pour chaque ligne de log (et conserver donc les écarts entre les accès). Si il existe une autre solution pour rejouer ces logs, ou simplement une solution de remplacement à at, je suis évidement preneur :)
Ouh là c'est violent comme méthode, l'idéal serait de convertir tes logs en actions pour un logiciel de tir de perf genre Tsung, Selenium ou autre qui sont vraiment fait pour cela. Je ne sais pas combien tu as d'entrée à la seconde mais tu risques surtout de saturer la machine en processus shell lancé par at qui vont lancés à leur tour un curl (3 process par url).
L'avantage aussi d'utiliser un logiciel de tir de perf c'est que tu pourras spliter la charge voulue sur plusieurs machines sources si une seule machine n'arrive pas à reproduire toute la charge voulue ou que tu satures en nombre de connexions, io réseau, ...
On Thu, 10 May 2012 20:49:26 +0200, "Mathieu Goessens" gebura@poolp.org said:
J'ai une série de logs web (plus précisément de logs de proxy au format squid), que je souhaites rejouer (pour tester les performances d'un proxy-cache distribué sur lequel je travail).
Au pif un petit bout de perl qui gere la temporisation avant de lancer les requetes ?
Salut,
Rejouer avec précision des requètes sur un proxy ? Le mieux serait peut-être de faire autrement :)
Je pensais à du tcpdump + tcpreplay qui te permettait un peu plus de souplesse avec surtout les headers qui vont avec, etc...
A moins que tu ne puisses pas reproduite le trafic que tu veux rejouer :S.
Cordialement, Pierre
2012/5/10 Mathieu Goessens gebura@poolp.org
Le 2012-05-10 20:42, Jean-Yves LENHOF a écrit :
Le 10/05/2012 18:11, Mathieu Goessens a écrit :
Bonjour,
Pour un usage sortant un peu de l'administration système (rejouer des logs), je cherche à utiliser at pour lancer des taches avec un niveau de précision de l'ordre de la seconde. Je comprends bien qu'il y aura des écarts (machines trop chargée, trop de forks..), mais je souhaiterais me rapprocher de cette échelle.
Tu peux nous expliquer un peu plus ce que tu souhaites faire véritablement ? Peut-être existe-t-il une autre solution que celle que tu cherches à suivre à tout prix...
J'ai une série de logs web (plus précisément de logs de proxy au format squid), que je souhaites rejouer (pour tester les performances d'un proxy-cache distribué sur lequel je travail).
Je pensais simplement programmer un curl avec at pour chaque ligne de log (et conserver donc les écarts entre les accès). Si il existe une autre solution pour rejouer ces logs, ou simplement une solution de remplacement à at, je suis évidement preneur :)
-- Mathieu Goessens IT consultant. gebura@poolp.org
- 33 6 07 91 54 87
http://gebura.eu.org ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, 10 May 2012 18:11:12 +0200, "Mathieu Goessens" gebura@poolp.org said:
geb@peeranha3:~$ echo 'date' | at -t 05101747.24
echo "sleep 24 ; date" | at -t 05101747
?????
-
Aurélien -
fouadlist -
Greg -
Jean-Yves LENHOF -
Mathieu Goessens -
Pierre Gaxatte -
Radu-Adrian Feurdean -
Wallace