Patrice Karatchentzeff a perdu son temps a nous dire:
Commenter une moyenne sans cart-type, c'est du n'importe quoi: ta machine peut trs bien avoir une moyenne de load de 0,001, si l'cart-type est de 80 (sic) alors t'es vachement bien barr dans les pics de charge...
Euh, c'est toi qui a commente le load average de la machine des le debut sans aucune information pertinente autre que le load average a un instant T, pas moi.
Pas un instant T : on a le dernier quart d'heure. Donc, en un quart d'heure, ta machine ne fait rien. C'est a priori un mauvais choix pour présenter une machine qui présente un long uptime et qui travaille.
Et tailler une machine pour qu'elle soit capable de supporter la rotation des logs, heu, comment dire... on se comprend, hein?
C'est parce que tu ne sais pas ce que sont des logs. Mais oui, il y a un certain niveau d'exigeances par rapport a la gestion des logs qui fait que ca fait partie des parametres pour sizer une machine.
Si c'est aussi critique sur un serveur que cela l'empêche(rait) de fonctionner dans sa mission première alors on les exporte ailleurs et on fait le traitement ad hoc déporté.
Patrice Karatchentzeff a perdu son temps a nous dire:
Commenter une moyenne sans cart-type, c'est du n'importe
quoi: ta machine peut trs bien avoir une moyenne de load de
0,001, si l'cart-type est de 80 (sic) alors t'es vachement bien
barr dans les pics de charge...
Euh, c'est toi qui a commente le load average de la machine des le
debut sans aucune information pertinente autre que le load average a
un instant T, pas moi.
Pas un instant T : on a le dernier quart d'heure. Donc, en un quart
d'heure, ta machine ne fait rien. C'est a priori un mauvais choix pour
présenter une machine qui présente un long uptime et qui travaille.
Et tailler une machine pour qu'elle soit capable de supporter la
rotation des logs, heu, comment dire... on se comprend, hein?
C'est parce que tu ne sais pas ce que sont des logs. Mais oui, il y
a un certain niveau d'exigeances par rapport a la gestion des logs
qui fait que ca fait partie des parametres pour sizer une machine.
Si c'est aussi critique sur un serveur que cela l'empêche(rait) de
fonctionner dans sa mission première alors on les exporte ailleurs et
on fait le traitement ad hoc déporté.
Patrice Karatchentzeff a perdu son temps a nous dire:
Commenter une moyenne sans cart-type, c'est du n'importe quoi: ta machine peut trs bien avoir une moyenne de load de 0,001, si l'cart-type est de 80 (sic) alors t'es vachement bien barr dans les pics de charge...
Euh, c'est toi qui a commente le load average de la machine des le debut sans aucune information pertinente autre que le load average a un instant T, pas moi.
Pas un instant T : on a le dernier quart d'heure. Donc, en un quart d'heure, ta machine ne fait rien. C'est a priori un mauvais choix pour présenter une machine qui présente un long uptime et qui travaille.
Et tailler une machine pour qu'elle soit capable de supporter la rotation des logs, heu, comment dire... on se comprend, hein?
C'est parce que tu ne sais pas ce que sont des logs. Mais oui, il y a un certain niveau d'exigeances par rapport a la gestion des logs qui fait que ca fait partie des parametres pour sizer une machine.
Si c'est aussi critique sur un serveur que cela l'empêche(rait) de fonctionner dans sa mission première alors on les exporte ailleurs et on fait le traitement ad hoc déporté.
Patrice Karatchentzeff , dans le message , a écrit :
Parce que balancer le load d'une machine
Il n'a pas balancé le load, il a balancé l'uptime. Que le load soit écrit à côté de l'uptime est une simple coïncidence.
qui ne fait a priori rien
Et tu recommences. Soit dit en passant, tu as raté quelque chose pendant ton passage sur les bancs de l'Éducation nationale : rien, c'est 0, et 0,14, ce n'est pas 0.
Patrice Karatchentzeff , dans le message
<87k4q8wa70.fsf@belledonne.chartreuse.fr>, a écrit :
Parce que balancer le load d'une machine
Il n'a pas balancé le load, il a balancé l'uptime. Que le load soit écrit à
côté de l'uptime est une simple coïncidence.
qui ne fait a priori rien
Et tu recommences. Soit dit en passant, tu as raté quelque chose pendant ton
passage sur les bancs de l'Éducation nationale : rien, c'est 0, et 0,14, ce
n'est pas 0.
Patrice Karatchentzeff , dans le message , a écrit :
Parce que balancer le load d'une machine
Il n'a pas balancé le load, il a balancé l'uptime. Que le load soit écrit à côté de l'uptime est une simple coïncidence.
qui ne fait a priori rien
Et tu recommences. Soit dit en passant, tu as raté quelque chose pendant ton passage sur les bancs de l'Éducation nationale : rien, c'est 0, et 0,14, ce n'est pas 0.
Nicolas George
ST , dans le message , a écrit :
C'est parce que tu ne sais pas ce que sont des logs. Mais oui, il y a un certain niveau d'exigeances par rapport a la gestion des logs qui fait que ca fait partie des parametres pour sizer une machine.
Ouais, mais si la rotation des logs implique de la charge, c'est soit que tu te farcis une application particulièrement mal conçue soit que c'est ton architecture de logs qui l'est.
ST , dans le message <m3h4e7-o7v.ln1@gulliver.unices.org>, a écrit :
C'est parce que tu ne sais pas ce que sont des logs. Mais oui, il y a un
certain niveau d'exigeances par rapport a la gestion des logs qui fait
que ca fait partie des parametres pour sizer une machine.
Ouais, mais si la rotation des logs implique de la charge, c'est soit que tu
te farcis une application particulièrement mal conçue soit que c'est ton
architecture de logs qui l'est.
C'est parce que tu ne sais pas ce que sont des logs. Mais oui, il y a un certain niveau d'exigeances par rapport a la gestion des logs qui fait que ca fait partie des parametres pour sizer une machine.
Ouais, mais si la rotation des logs implique de la charge, c'est soit que tu te farcis une application particulièrement mal conçue soit que c'est ton architecture de logs qui l'est.
ST
Patrice Karatchentzeff a perdu son temps a nous dire:
Pas un instant T : on a le dernier quart d'heure. Donc, en un quart d'heure, ta machine ne fait rien. C'est a priori un mauvais choix pour présenter une machine qui présente un long uptime et qui travaille.
Non, une machine avec un faible load average n'est pas une machine qui ne fait rien. C'est une machine bien geree dont les applicatifs sont bien ecrits et ne generent pas de charge inutile.
C'est egalement une machine qui a ete sizee pour supporter des pics et une montee en charge qui se gere pas en urgence.
Mais bon apres, t'as le droit de travailler comme un bourrin, d'avoir des machines chargees en permanence et meme de considerer que c'est normal.
Mais tu m'excuses, je gere des serveurs qui ont des pics de traffic de 1 a 100 sur une journee, qui sont utilisees par des operateurs telephoniques sur une base de plusieurs millions d'utilisateurs. J'ai pas le luxe d'economiser dans la bidouille pour le plaisir de voir du load average.
Le load average est une donnee technique et quand un serveur affiche un superieur a quelques unitees en temps de production normal, c'est simplement qu'il est temps d'investir.
Si c'est aussi critique sur un serveur que cela l'empêche(rait) de fonctionner dans sa mission première alors on les exporte ailleurs et on fait le traitement ad hoc déporté.
C'est bien ce que je dis, tu ne sais meme pas ce que sont des logs.
-- On l'avait appele Jacouille, pas seulement a cause de ses dents, mais aussi a cause de son air un peu bete. Il nous repondait "Mon nom est Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Patrice Karatchentzeff a perdu son temps a nous dire:
Pas un instant T : on a le dernier quart d'heure. Donc, en un quart
d'heure, ta machine ne fait rien. C'est a priori un mauvais choix pour
présenter une machine qui présente un long uptime et qui travaille.
Non, une machine avec un faible load average n'est pas une machine qui
ne fait rien. C'est une machine bien geree dont les applicatifs sont
bien ecrits et ne generent pas de charge inutile.
C'est egalement une machine qui a ete sizee pour supporter des pics
et une montee en charge qui se gere pas en urgence.
Mais bon apres, t'as le droit de travailler comme un bourrin, d'avoir
des machines chargees en permanence et meme de considerer que c'est
normal.
Mais tu m'excuses, je gere des serveurs qui ont des pics de traffic de 1
a 100 sur une journee, qui sont utilisees par des operateurs
telephoniques sur une base de plusieurs millions d'utilisateurs. J'ai
pas le luxe d'economiser dans la bidouille pour le plaisir de voir du
load average.
Le load average est une donnee technique et quand un serveur affiche un
superieur a quelques unitees en temps de production normal, c'est
simplement qu'il est temps d'investir.
Si c'est aussi critique sur un serveur que cela l'empêche(rait) de
fonctionner dans sa mission première alors on les exporte ailleurs et
on fait le traitement ad hoc déporté.
C'est bien ce que je dis, tu ne sais meme pas ce que sont des logs.
--
On l'avait appele Jacouille, pas seulement a cause de ses dents, mais
aussi a cause de son air un peu bete. Il nous repondait "Mon nom est
Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous
on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Patrice Karatchentzeff a perdu son temps a nous dire:
Pas un instant T : on a le dernier quart d'heure. Donc, en un quart d'heure, ta machine ne fait rien. C'est a priori un mauvais choix pour présenter une machine qui présente un long uptime et qui travaille.
Non, une machine avec un faible load average n'est pas une machine qui ne fait rien. C'est une machine bien geree dont les applicatifs sont bien ecrits et ne generent pas de charge inutile.
C'est egalement une machine qui a ete sizee pour supporter des pics et une montee en charge qui se gere pas en urgence.
Mais bon apres, t'as le droit de travailler comme un bourrin, d'avoir des machines chargees en permanence et meme de considerer que c'est normal.
Mais tu m'excuses, je gere des serveurs qui ont des pics de traffic de 1 a 100 sur une journee, qui sont utilisees par des operateurs telephoniques sur une base de plusieurs millions d'utilisateurs. J'ai pas le luxe d'economiser dans la bidouille pour le plaisir de voir du load average.
Le load average est une donnee technique et quand un serveur affiche un superieur a quelques unitees en temps de production normal, c'est simplement qu'il est temps d'investir.
Si c'est aussi critique sur un serveur que cela l'empêche(rait) de fonctionner dans sa mission première alors on les exporte ailleurs et on fait le traitement ad hoc déporté.
C'est bien ce que je dis, tu ne sais meme pas ce que sont des logs.
-- On l'avait appele Jacouille, pas seulement a cause de ses dents, mais aussi a cause de son air un peu bete. Il nous repondait "Mon nom est Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
ST
Patrice Karatchentzeff a perdu son temps a nous dire:
Parce que balancer le load d'une machine qui ne fait a priori rien comme preuve d'une machine qui a un gros uptime est ridicule...
Non, et ca n'a meme aucun rapport. Mais il faudrait deja quelques competences a ce niveau pour le comprendre.
Demande a JKB, il t'expliquera.
-- On l'avait appele Jacouille, pas seulement a cause de ses dents, mais aussi a cause de son air un peu bete. Il nous repondait "Mon nom est Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Patrice Karatchentzeff a perdu son temps a nous dire:
Parce que balancer le load d'une machine qui ne fait a priori rien comme
preuve d'une machine qui a un gros uptime est ridicule...
Non, et ca n'a meme aucun rapport. Mais il faudrait deja quelques
competences a ce niveau pour le comprendre.
Demande a JKB, il t'expliquera.
--
On l'avait appele Jacouille, pas seulement a cause de ses dents, mais
aussi a cause de son air un peu bete. Il nous repondait "Mon nom est
Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous
on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Patrice Karatchentzeff a perdu son temps a nous dire:
Parce que balancer le load d'une machine qui ne fait a priori rien comme preuve d'une machine qui a un gros uptime est ridicule...
Non, et ca n'a meme aucun rapport. Mais il faudrait deja quelques competences a ce niveau pour le comprendre.
Demande a JKB, il t'expliquera.
-- On l'avait appele Jacouille, pas seulement a cause de ses dents, mais aussi a cause de son air un peu bete. Il nous repondait "Mon nom est Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
ST
Nicolas George a perdu son temps a nous dire:
Ouais, mais si la rotation des logs implique de la charge, c'est soit que tu te farcis une application particulièrement mal conçue soit que c'est ton architecture de logs qui l'est.
Ben quand tu compresses 300GB de logs, ca genere de la charge. Moi je veux bien ecrire aux petits gars de gzip pour leur dire que c'est pas normal, mais ils vont peut etre un tout petit peu se foutre de moi.
Je prefere considerer que ca va me prendre un des CPU pendant un temps X une fois pas jour/semaine et sizer ma machine en consequence.
de la meme facon, les backup generent de la charge. Autant a la creation du backup, a la compression et a l'envoi sur l'equipement de stockage qui va storer le tout.
Bref, avec 16 proc, une charge de 0.5 a 1.5 en prod, on monte a 4 pdt la compression des logs ou les backup et l'impact sur le traffic est nul.
Alors que si la machine etait deja a 4 en situation normale (disons qu'elle a moins de CPU ou une carte RAID au lieu d'un SAN), la rotation des logs pousserait le load average au dela du nombre de CPU et il y aurait un impact sur le traffic.
-- On l'avait appele Jacouille, pas seulement a cause de ses dents, mais aussi a cause de son air un peu bete. Il nous repondait "Mon nom est Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Nicolas George a perdu son temps a nous dire:
Ouais, mais si la rotation des logs implique de la charge, c'est soit que tu
te farcis une application particulièrement mal conçue soit que c'est ton
architecture de logs qui l'est.
Ben quand tu compresses 300GB de logs, ca genere de la charge. Moi je
veux bien ecrire aux petits gars de gzip pour leur dire que c'est pas
normal, mais ils vont peut etre un tout petit peu se foutre de moi.
Je prefere considerer que ca va me prendre un des CPU pendant un
temps X une fois pas jour/semaine et sizer ma machine en consequence.
de la meme facon, les backup generent de la charge. Autant a la creation
du backup, a la compression et a l'envoi sur l'equipement de stockage
qui va storer le tout.
Bref, avec 16 proc, une charge de 0.5 a 1.5 en prod, on monte a 4 pdt
la compression des logs ou les backup et l'impact sur le traffic est
nul.
Alors que si la machine etait deja a 4 en situation normale (disons
qu'elle a moins de CPU ou une carte RAID au lieu d'un SAN), la rotation
des logs pousserait le load average au dela du nombre de CPU et il y
aurait un impact sur le traffic.
--
On l'avait appele Jacouille, pas seulement a cause de ses dents, mais
aussi a cause de son air un peu bete. Il nous repondait "Mon nom est
Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous
on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Ouais, mais si la rotation des logs implique de la charge, c'est soit que tu te farcis une application particulièrement mal conçue soit que c'est ton architecture de logs qui l'est.
Ben quand tu compresses 300GB de logs, ca genere de la charge. Moi je veux bien ecrire aux petits gars de gzip pour leur dire que c'est pas normal, mais ils vont peut etre un tout petit peu se foutre de moi.
Je prefere considerer que ca va me prendre un des CPU pendant un temps X une fois pas jour/semaine et sizer ma machine en consequence.
de la meme facon, les backup generent de la charge. Autant a la creation du backup, a la compression et a l'envoi sur l'equipement de stockage qui va storer le tout.
Bref, avec 16 proc, une charge de 0.5 a 1.5 en prod, on monte a 4 pdt la compression des logs ou les backup et l'impact sur le traffic est nul.
Alors que si la machine etait deja a 4 en situation normale (disons qu'elle a moins de CPU ou une carte RAID au lieu d'un SAN), la rotation des logs pousserait le load average au dela du nombre de CPU et il y aurait un impact sur le traffic.
-- On l'avait appele Jacouille, pas seulement a cause de ses dents, mais aussi a cause de son air un peu bete. Il nous repondait "Mon nom est Jacques, pas Jacouille !". Depuis il a change de nom, pour Kojak. Nous on l'appele "Inspecteur", mais c'est surtout a cause des cheveux.
Nicolas George
ST , dans le message , a écrit :
Ben quand tu compresses 300GB de logs, ca genere de la charge.
En nice 19, évidemment. Donc on s'en fout, ça n'impacte pas le reste du fonctionnement.
ST , dans le message <vkq4e7-8ff2.ln1@gulliver.unices.org>, a écrit :
Ben quand tu compresses 300GB de logs, ca genere de la charge.
En nice 19, évidemment. Donc on s'en fout, ça n'impacte pas le reste du
fonctionnement.
Ben quand tu compresses 300GB de logs, ca genere de la charge.
En nice 19, évidemment. Donc on s'en fout, ça n'impacte pas le reste du fonctionnement.
Patrice Karatchentzeff
Nicolas George <nicolas$ a écrit :
Patrice Karatchentzeff , dans le message , a écrit :
Parce que balancer le load d'une machine
Il n'a pas balancé le load, il a balancé l'uptime. Que le load soit écrit à côté de l'uptime est une simple coïncidence.
C'est idiot ta remarque : je remarquais que justement, puisque l'info est *aussi* fournie, sa remarque ne voulait rien dire.
qui ne fait a priori rien
Et tu recommences. Soit dit en passant, tu as raté quelque chose pendant ton passage sur les bancs de l'Éducation nationale : rien, c'est 0, et 0,14, ce n'est pas 0
D'accord. Si tu veux ergoter comme un esthète, apprend à citer correctement avant : ça fera moins nouille.
Nicolas George <nicolas$george@salle-s.org> a écrit :
Patrice Karatchentzeff , dans le message
<87k4q8wa70.fsf@belledonne.chartreuse.fr>, a écrit :
Parce que balancer le load d'une machine
Il n'a pas balancé le load, il a balancé l'uptime. Que le load soit écrit à
côté de l'uptime est une simple coïncidence.
C'est idiot ta remarque : je remarquais que justement, puisque l'info
est *aussi* fournie, sa remarque ne voulait rien dire.
qui ne fait a priori rien
Et tu recommences. Soit dit en passant, tu as raté quelque chose
pendant ton passage sur les bancs de l'Éducation nationale : rien,
c'est 0, et 0,14, ce n'est pas 0
D'accord. Si tu veux ergoter comme un esthète, apprend à citer
correctement avant : ça fera moins nouille.
Patrice Karatchentzeff , dans le message , a écrit :
Parce que balancer le load d'une machine
Il n'a pas balancé le load, il a balancé l'uptime. Que le load soit écrit à côté de l'uptime est une simple coïncidence.
C'est idiot ta remarque : je remarquais que justement, puisque l'info est *aussi* fournie, sa remarque ne voulait rien dire.
qui ne fait a priori rien
Et tu recommences. Soit dit en passant, tu as raté quelque chose pendant ton passage sur les bancs de l'Éducation nationale : rien, c'est 0, et 0,14, ce n'est pas 0
D'accord. Si tu veux ergoter comme un esthète, apprend à citer correctement avant : ça fera moins nouille.
