Non, non - il a raison.
Il ne faut pas oublier que le budget total de la sécu est de 311 Milliards - donc même si les 10MM (13MM avec la TVA et les taxes de transport) de taxes étaient reversées on peut comprendre que ca ne touche pas change pas forcément grand chose.
Maintenant la question est de savoir quelle part du budget de la sécu sert aux soins des fumeurs et des personnes souffrant de tabagie passive.
Difficile à dire. Si on balaye très très large (mais alors gras) et que l'on impute la lutte contre le tabagisme, les estimations de pertes de productivité (congés maladie, durée des pauses, cout de formation des personnes pour remplacer un fumeur décédé/incapacité etc.) et bien entendu tous les cancers de gens ayant fumé au moins uen fois dans leur vie (85% des cas de cancer du poumon - mais pas loin de 12% de cas "atypique" c'est à dire des cancers n'ayant pas les caractéristiques du cancer classique du fumeur) on arrive de mémoire à prêt de 50MM d'€.
Donc la les 13MM d'€ font pale figure.
Sauf qu'il ne faut pas oublier non plus que les fumeurs en France représentent plus de 30% de la population (Et oui, plus d'un français (agé de 18 à 74 ans) sur trois fume plus qu'occasionellement - ie plus d'une cigarette par jour), mais également ils cotisent aussi à la sécu pour un montant de plus de 100MM d'€. Donc techniquement ils coutent (maxi) 50MM d'€ à la société dans son ensemble - mais ils rapportent 113 MM d'€ au gouvernement au titre de la santé publique.
Ca reste très profitable pour le gouvernement (carrément moins pour les entreprises qui embauchent des fumeurs).
Euh 22k€ ? Tu paie a peine les examens qu'il faudra te faire lorsque tu auras ton cancer, pas le traitement , encore moins si il y a du bloc, du paliatif et la maladie chronique.
Le cancer du poumon est un des moins cher à traiter (car un des plus courant - donc un de ceux pour lesquels les concurrences sur les médicaments est rude.)
Egalement "seulement" 15% des fumeurs (dans l'approche la plus pessimiste) développent un cancer du poumon. On peut ajouter à celà que 15% des personnes n'ayant jamais fumé, ni fréquenté de fumeurs de façon significative, font également un cancer du poumon (N.B : une autre variante qui est plus longue et plus cher à traiter).
22'000 euros ouais… ca doit bien faire 10% du cout d'un traitement contre le cancer je pense, au maximum.
Rappel (j'en ai déjà fait plusieurs https://linuxfr.org/nodes/94279/comments/1353965 ) si toutes les taxes percues au titre des ventes de produits sur le tabac étaient reversée à la sécu on reboucherait le trou de la sécu en 3 ans.
Si on laisse la TVA de coté, il faut 5 ans.
Donc oui les taxes percues au titre du tabac compensent largement (hint tous les fumeurs ne choppent pas le cancer).
Bon, gros malin, tu vas aller me deployer un HAProxy, le charger ras la gueule jusqu'a saturer ton lien gigabit.
Ensuite, tu vas prendre la version modifier, et tu vas faire la meme chose.
a) Avec HAProxy ce sont plutot des liens 10Gb que je sature, généralement par paquet de quatre (sinon les fusion I/O se sentent inutiles)
b) Il existe déjà un excellent proxy sur-optimisé avec un controlleur très très light pour le HTTP : NGINX. Et ben tu sais quoi, il se fait battre par HAProxy au niveau perfs pures (d'un autre coté aussi il fait beaucoup plus de choses que HAProxy - et en plus on peut assez facilement les combiner c'est du bonheur)
c) Le wrapper n'existe pas encore - donc pour les benchs il va falloir attendre.
d) Parmis les benchs des trucs qui m'intéressement il y a le temps que met HAProxy à redémarrer et pour quel cout CPU - Sur cet partie du bench je peux te garantir que je pourrais faire la différence à 100% entre les deux versions même si les temps de respawn sont rigoureusement identiques. Ne serait-ce qu'en surveillant les context swap.
matériel ?
si oui, ce n'est plus de la maintenance, c'est de la défaillance
Bof, personellement les mises à jours de firmwares, les perfs de backplane à retweaker en permanence pour cause de mise à jour de firmware, les ventilos à passer en mode "à donf" en permanence pour limiter la chauffe CPU je passe ça en case "maintenance".
De façon générale la défaillance c'est ce qui me casse les pieds mais qui ne me prend pas du temps (enfin le temps d'un cout de fil au support pour qu'ils viennent changer la pièce). La maintenance c'est ce qui mobilise un technicien ou plus pendant deux heures pour faire repartir la machine (éventuellement en mode dégradé faute de mieux).
Maintenant c'est mon vocabulaire à moi, je suis pas sur du tout que l'académie soit de mon coté sur le coup.
mais lorsque je te vois critiquer un process de contrôle pour des raisons de performances, je trouve ça quand même assez cocasse :)
Ben écoute tu le prends comme tu veux. On va juste dire que l'auteur du logiciel haproxy refuse les controlleurs pour des raisons de performances - et accessoirement il a le proxy TCP le plus rapide et le plus léger que je connaisse. Peut-être qu'il se trompe et qu'un controlleur n'aurait pas d'impact sur les perfs, en attendant et depuis dix ans, c'est lui qui tiens la position de tête au niveau proxy. Donc tout bien pris en compte, il semblerait que son choix ne soit pas idiot.
Ce sont des jeux d'instruction du processus qui permettent de faire le mapping entre la mémoire virtuelle des machines virtuelles et la mémoire virtuelle de la machine hote. La solution software (shadow pages) est souvent (beaucoup) plus lente.
mais j'aurais adoré pouvoir jouer avec un Opteron et voir ce que ça a dans le ventre.
A l'époque (4 ans) en virtualisation ca envoyait du lourd - quand ca marchait. Sur VMWare on avait des gains de perfs jusqu'à 50% sur des applis java lourde (à machine de prix comparable).
Aujourd'hui je ne sais pas. Mais je ne suis pas sur que ce soit rentable - de totue façon il y avait trop de maintenance.
Par contre je me pose des questions sur la légitimité de la domination des Xeon, je n'ai jamais vu un seul serveur en Opteron.
Ben écoute, pour avori pas mal utilisé des (gros) serveurs opterons à l'époque ou les serveurs Xeon ne prenaient pas en charge le nested paging (RVI ca s'appelle maintenant), je peux te dire que je suis vraiment content que ca existe sous Xeon maintenant.
Je sais pas si le problème venait des cartes mères, des CPU eux-mêmes ou du lot de processeurs qu'on a reçu - mais on a eu un taux de pannes reccord pendant deux ans.
très pénalisant de garder un pointeur vers la config pour chaque socket d'ouverte ? ça ajoute au pire une indirection de pointeurs quand tu veux accéder aux infos.
Sur un logiciel dont le but est d'ouvrir des centaines de milliers de connexions par seconde - oui c'est pénalisant.
Ensuite il ne suffit pas d'avoir la config du socket coté proxyC ou proxyS , mais assez de metas données pour pouvoir "deviner" que la connexion sur le port TCP 12312 est une session FTP passif et que donc lorsque je vais recevoir une demande d'ouverture de port sur le 12313 par le même client, il va falloir que je l'accepte et que je le redirige vers le bon serveur en cas d'authentification etc.
Tout ceci n'est pas le boulot d'un proxy TCP. C'est éventuellement le boulot d'un routeur/firewall coeur de réseau.
Tu balances cette phrase comme si c'était normal
Ca l'est
Bon, quand tu me demanderas d'aller à gauche, j'irai tout droit
Ben dans ce cas tu ne fais pas ce que je t'ai demandé. Quand je demande un reload et qu'un serveur fait un restart il fait ce que je lui ai demandé (ie prendre en compte la nouvelle config). Si le concepteur du logiciel estime que pour prendre en compte la nouvelle config il faut nécessairement faire un restart, il est probable qu'il ait raison.
et c'est tout à fait légitime que systemd essaye de forcer les soft à être corrigés plutôt que de permettre des bidouilles.
Non.
Le truc c'est que le reload est déjà en lui même une bidouille - bien pratique certes, mais une bidouille. C'est même une bidouille assez récente en vrai et pas mal de versions un peu ancienne des logiciels ne supportent pas le reload et/ou l'interpretent comme un restart (On parle de trucs assez mainstream, genre apache 1 ou encore sendmail) et il y a encore pas mal de paramètres de pas mal de daemons qui nécessitent de toutes les façon un restart pour être prise en compte (un simple reload ne suffisant pas).
Pour signifier le reload on utilise une autre bidouille : envoyer à un daemon un signal qui n'a rien à voir avec la choucroute. Le SIGHUP sur un daemon c'est comme un poisson avec une bicyclette, si on est pas prévenu on voit pas vraiment ce que l'un et l'autre font ensemble.
Pour systemd c'est encore une bidouille de plus : si un daemon n'a pas d'interface DBus, alors on va lui envoyer un petit SIGHUP pour lui dire de recharger sa config. Donc je ne sais rien du daemon, on a pas d'interfaces pour dialoguer ensemble, mais je vais partir des principes suivants :
a) il a une fonction reload
b) cette fonction reload peut être déclenchée par un SIGHUP
c) Mon SIGHUP sera nécessairement pris en compte et le reload fonctionnera nécessairement (on a toujours pas d'interface pour dialoguer - donc si le serveur répond "pas maintenant" ou "j'ai pas les droits sur le fichier de config" on l'a dans l'os)
d) Ca ne génèrera pas de restart du daemon
e) Accessoirement quand on fait un reload de tel ou tel processus il n'y a pas de pre ou de post traitements à faire.
Bien entendu ca marche dans 99% des cas avec des daemons relativement modernes dans des paramétrages relativement standard - mais de là à dire que c'est de la lutte contre la bidouille (alors qu'il y en a déjà trois grosses pour mettre en place cette "lutte") et que systemd peut s'accorder le droit de faire comme il veut "pour le bien de tous", permet moi d'être circonspect.
Si les démons font la différence entre reload, reload_now et force_reload (avec toutes les variantes possibles et immaginables) c'est bien que SIGHUP à la barbare ne suffit pas, chercher à l'imposer comme LA référence est idiot. (Et ce n'est d'ailleurs pas le but de systemd - le hack du SIGHUP c'est plus un mode de compatibilité qu'autre chose.)
Il suffit pas tout simplement de binder une connextion avec une config en lecture seule et de binder les nouvelles connexions avec la nouvelle config ? Voila tu as évité ton effet de bord diabolique.
Le problèmes est que tu ne peux pas faire la différence entre la continuation d'une ancienne connexion et une nouvelle connexion "simplement".
Prend le FTP pasif comme exemple. Ou une connexion avec un tunnel. Autant tu peux suivre la connexion "au fil de l'eau" autant quand tu vas changer ton proxy (ce qui veut dire que tu vas avoir un autre processus qui va se mettre à écouter sur une plage de port) tu vas te retrouver comme un con en voyant arriver les demandes. Tu as besoin des infos qui sont dans l'ancienne appli pour t'assurer que la connexion sur le port X est nouvelle ou ancienne, connue ou inconnue. Et ca serait très pénalisant au niveau perf de faire ça.
ça doit être bien dégueulasse le script sysV pour le coup, parce que là, même avec les cgroups, on arrive à paumer le daemon en cours de route
Euh non. Les scripts init pour haproxy font normalement tous un peu la même chose : quand on demande un reload, on se prend un restart.
C'est un choix qui a été fait, pour éviter les abus et tout les hacks sales des init sysV.
C'est bien pour ça que j'ai dit que ca n'est pas la faute de systemd non plus. Le choix de limiter le nombre de commandes dans systemctl ne me choque pas plus que ça. (Par contre l'absence de templates dignes de ce nom ou la impossibilité de faire des interactions utilisateurs pendant l'init me hérissent - mais c'est un autre débat).
Arrête de me faire rire… le controlleur il est juste là à attendre des signaux… il n'a aucun impact sur la perf du process qui est controllé.
Il y a pas que SIGHUP dans la vie.
Les autres signaux m'interressent peut être, et peut-être que le fait de les recevoir quelques microsecondes plus tôt et sans context switch m'interresse.
Ensuite même si il ne fait que d'écouter les signaux et les rebalancer il me prend quand même de la mémoire, du CPU etc. Alors qu'il ne me sert à rien si je n'ai pas systemd.
Ici le cas c'est, je lance un nouveau process avec nouvelle config, j'attend que le vieux process arrête son travail en cours proprement et s'arrête
Sauf que ton nouveau process ne pourra pas être actif tant que l'ancien n'est pas arrété (sinon bonjour le mic-mac au niveau des sessions) et que donc tu vas perdre des connexions. Si il y a un mec qui a décidé de télécharger un projet de plusieurs Go, tu es juste bloqué pendant des heures sans pouvoir accepter de connexions.
Ou alors tu essayes de finir les sessions actives pendant un temps raisonnables (on va dire 10 secondes) mais sur un site à forte demande ca n'est pas top non plus. Et en plus tu finis quand même par fermer tout brutalement et te relancer si toutes les sessions ne sont pas closes au bout de 10sec.
La meilleure solution (en fait la seule qui soit viable) consiste à tout foutre par terre et à laisser les serveurs se démerder si ils veulent de la résistance/de la reprise de session logique. C'est d'ailleurs la solution adoptée par tout le monde (NGINX, apache mod_proxy, squid etc.)
il suffit de faire correctement le wrapper et il sera générique
On peut effectivement faire un controlleur "light" plutôt qu'un wrapper spécifique à systemd.
Sauf que je ne vois pas pourquoi j'irais perdre des perfs avec un controlleur, alors que je cherche au contraire à en gagner le plus possible.
Problème systemd => Verrue systemd.
les autres daemons n'en ont pas besoin, preuve que c'est non-nécessaire
Tout à fait, et d'ailleurs les autres démons n'ont pas besoin de 99% de ce qu'utilise un démon pris au hasard. Preuve que les démons c'est non nécessaire.
Ou alors c'est juste qu'il y a très peu de démons en mode single processus pour qui un reload dynamique est hors de question.
Comment tu transfères une session sécurisée ?
Comment tu fais la différence entre un nouveau serveur et un serveur qui a juste changé d'IP
Comment tu prend en compte le load-balancing/le session queuing/les flags TCP ?
Comment tu réadresse tes lans/vlans ?
Comment tu notifies les clients et les serveurs de tes décisions ?
etc.
On est pas juste dans le domaine de la paresse, il faudrait uen norme complète de prise en charge des modifications de topologie aussi bien au niveau client que serveur, et un proxy avec des tables de suivi de cent pieds de long. Grosso modo ca revient à transformer le proxy en firewall/router coeur de réseau. C'est un poil overkill pour la plupart des applications non ?
Tu peux en discuter avec le mec d'haproxy si tu veux, son design single process est actuellement le proxy le plus rapide disponible pour un cout CPU ridicule.
je vois pas ce que processus unique ou non, que ce soit un proxy ou un lecteur audio ou un livre de schtroumph y change quoi que ce soit
Une appli standard a tout intéret à conserver son état interne quelque part et à disposer en permanence de tous les éléments pour comprendre et analyser cet état.
Un proxy n'a aucun intéret à faire celà, il doit faire de la mise en relation le plus rapidement possible entre des clients et des serveurs. A partir de la une question comme "comment on en est arrivé là" ne l'interresse pas. Pour être capable de recharger dynamiquement une config un proxy devrait être capable de comprendre pour quel raison il est dans l'état présent, de réinterpréter l'état en fonction de la nouvelle config et de notifier de façon transparente le client et le serveur des décisions qu'il a prise. Sur un proxy générique comme haproxy c'est tout simplement impossible (ne serait-ce que de convaincre un autre serveur http de reprendre une session modifiée comme si c'était une des siennes ca va être coton, à moins d'en avoir rien à faire de la sécurité du bigniou).
Donc un proxy raisonnablement générique n'a pas vraiment d'autre choix que de redémarrer à chaque changement de config. Et si on doit redémarrer ET que l'on est en architecture processus unique ben paf le systemd.
1* il y a un déjà un wrapper
Pas encore il est en cours d'écriture
2* celui-ci agit mal
Vu le chemin choisi, il n'agira pas plus mal qu'un controlleur NGINX
3* le patch proposé contient des if (systemd) ce qui semble absurde.
Pas plus absurde qu'autre chose. Sur un init classique je n'ai pas besoin de l'overhead lié à systemd - donc autant s'en passer. Surtout que généralement quand on utilise haproxy c'est que l'on veut utiliser jusqu'à la dernière goutte de CPU disponible pour créer des connexions. Personellement je serais même pour un configure --without-systemd (ce qui j'imagine dans ta vision serait encore pire).
Faut que tu m'explique en quoi ça ne ferait plaisir qu'à systemd (et personne d'autre), dans le patch proposé je ne vois rien qui est un ajout, juste un test en plus pour activer du code qui existe déjà.
Tu as encore mal lu (décidément c'est récurrent), il prépare le terrain pour du code qui n'existe pas encore :
I'm writing a wrapper around it and the corresponding systemd service file. I will provide them
once they are fully ready. (What could be the name of this wrapper, by the way? haproxy-systemd-wrapper?)
C'est quand même dingue qu'a vous lire, toute la puissance de haproxy réside dans son code de reload de config
Je réexplique pour les personnes un peu lente.
Toute la puissance d'haproxy vient du fait qu'il est à processus unique, piloté par évennement. (Single process, event driven).
Sur ce genre d'appli (un proxy en mode processus unique) il n'est pas possible de mettre à jour la config de façon dynamique. Il n'existe pas de méthode pour aglomérer intelligeament l'ancienne config et la nouvelle (les serveurs peuvent avoir changés d'ip ou de nom, certaines sessions autorisées peuvent être interdite, le poids de load balancing peut avoir été changé etc.)
A partir de la quand on modifie la config d'un proxy la seule bonne façon de faire est de tuer et de relancer les processus de proxification et de repartir à 0.
Si il y a un controlleur dédié (ie le daemon n'est pas le processus de proxification) alors le controlleur relance les processus fils un par un (c'est le cas pour nginx) mais dans le cas d'une appli à processus unique la SEULE façon de faire est de relancer complètement le processus.
A partir de là forcément il faut créer un "pseudo controlleur" pour devenir compatible avec systemd. Le "pseudo controlleur" ne fera rien d'autre que de lancer haproxy et de lui passer les messages systemes (d'ou le "pseudo").
Donc en fait : proxy+architecture à processus unique = on relance tout en cas de changement de config.
Le pseudo controlleur ne sert à rien d'autre qu'à faire plaisir à systemd d'ou le terme de wrapper.
J'aime bien : devoir adapter en faisant 10 lignes de code (et elles sont faites, tu ne perds absolument rien, on 'l'a déjà fait pour toi, comme des millions d'autres petites adaptations faites par des logiciels pour la compatibilité),
Tu as mal lu. les dix petites lignes de codes ne sont pas là pour changer le comportement de Haproxy (qui est le bon), mais pour lui permettre d'être piloté par le wrapper systemd.
Donc le démon n'est pas normalisé, il continue à fonctionner exactement comme avant, mais il a maintenant une interface de plus pour être piloté un wrapper.
Tu ne fais que démontrer que systemd est nécessaire, afin de forcer les daemons à être standard
Quitte à perdre au passage le proxy le plus performant disponible ?
Sans façon non.
Haproxy est un excellent proxy avec des perfs que ce soit en conso CPU ou en nombre de connexions par secondes qui sont inégalées.
Ceci est du à son architecture processus unique qui ne changera pas (et qui ne doit pas changer).
D'ailleurs la solution apportée est de créer un wrapper, pas de modifier le comportement de haproxy.
Donc non, il n'existe déjà pas de démons standards - et systemd ne va rien faire pour améliorer les choses.
Tu fais exprès ou t'as jamais lu le "Advanced Programming in the Unix Environment" de feu Dr Stevens ?_
Un daemon unix est sensé recharger sa configuration quand on lui envoie le signal SIGHUP,_
J'imagine que tu fais référence au chapitre 13.6
To avoid this, some daemons will catch SIGHUP and reread their configuration files when they receive the signal. Since they aren't associated with terminals and are either session leaders without controlling terminals or members of orphaned process groups, daemons have no reason to expect to receive SIGHUP. Thus, they can safely reuse it.
Si c'est bien le cas
a) Il s'agit de conventions, pas de normes. L'utilisation de sighup pour recharger la config est un hack. C'est d'ailleurs mentionné dans le texte.
b) Dans le cas d'un proxy (surtout en mode load balancing) ca n'a pas vraiment de sens de garder les process actifs vivants au moment d'un changement de config - et comme haproxy est en mode processus unique architecturalement, forcément il redémarre (d'ailleurs Nginx redémarre tous les workers en cas de changement de config, qu'il soit en mode proxy ou non)
c) Haproxy est très correctement écrit, il a des perfs monstrueuses, fonctionne sans failles connues depuis 2002, est utilisé par des milliers de serveurs à travers le monde etc.
Son architecture processus unique le rend incompatible avec systemd sans un wrapper - ca n'est ni un défaut de haproxy, ni pour le coup réellement un défaut de systemd. Ca serait mieux si on pouvait passer des commandes aux serveurs directement via systemctl (des commandes non interprétées je veux dire) mais ca n'est pas possible (cette fois par design de systemd).
Je maintiens aussi que ne pas vouloir changer ses habitudes pour utiliser Gnome3 est un PEBKAC.
Oui, enfin si changer ses habitudes ca veut dire réécrire les .desktop, remonter des bugs pour chaque .desktop mal écrit et passer en locale en_US, ben je vais pas changer mes habitudes.
Ceci dit même si j'ai essayé Gnome3/Gnome-shell, je n'ai pas vraiment insisté. J'utilise Mate et j'en suis très très content.
Mes applis Linux X11 de référence (Dia, Gimp, LibreOffice, firefox etc.) sont encore en GTK2 et les déclarations du projet Gnome au sujet de Gnome3 me donnent plutôt envie de rester le plus éloigné possible de Gnome-shell et toute la clique.
Les applis que je lance fréquamment je les envoie avec des raccourcis claviers (ce qui pose des problèmes à faire sous Gnome-shell) mes applis moins courantes sont accessibles très rapidement via des menu custom (auquel j'accède sans la souris d'ailleurs) et les applis dont je me sers rarement sont rangées dans un menu qui fait sens pour moi. Donc avant que les "améliorations" de Gnome-Shell me fassent gagner du temps il va se passer des choses. Surtout que les mises à jour Gnome-shell ont la sale manie de casser/interdire les customisations qu'on avait mis en place.
J'ai branché mon cerveau après plusieurs heures de config et de rage avec les mises à jour et je suis passé sur Mate. Depuis tout va mieux.
[^] # Re: Ne pas confondre ...
Posté par Kaane . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 7.
Non, non - il a raison.
Il ne faut pas oublier que le budget total de la sécu est de 311 Milliards - donc même si les 10MM (13MM avec la TVA et les taxes de transport) de taxes étaient reversées on peut comprendre que ca ne touche pas change pas forcément grand chose.
Maintenant la question est de savoir quelle part du budget de la sécu sert aux soins des fumeurs et des personnes souffrant de tabagie passive.
Difficile à dire. Si on balaye très très large (mais alors gras) et que l'on impute la lutte contre le tabagisme, les estimations de pertes de productivité (congés maladie, durée des pauses, cout de formation des personnes pour remplacer un fumeur décédé/incapacité etc.) et bien entendu tous les cancers de gens ayant fumé au moins uen fois dans leur vie (85% des cas de cancer du poumon - mais pas loin de 12% de cas "atypique" c'est à dire des cancers n'ayant pas les caractéristiques du cancer classique du fumeur) on arrive de mémoire à prêt de 50MM d'€.
Donc la les 13MM d'€ font pale figure.
Sauf qu'il ne faut pas oublier non plus que les fumeurs en France représentent plus de 30% de la population (Et oui, plus d'un français (agé de 18 à 74 ans) sur trois fume plus qu'occasionellement - ie plus d'une cigarette par jour), mais également ils cotisent aussi à la sécu pour un montant de plus de 100MM d'€. Donc techniquement ils coutent (maxi) 50MM d'€ à la société dans son ensemble - mais ils rapportent 113 MM d'€ au gouvernement au titre de la santé publique.
Ca reste très profitable pour le gouvernement (carrément moins pour les entreprises qui embauchent des fumeurs).
[^] # Re: Ne pas confondre ...
Posté par Kaane . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 2.
http://www.assureo.fr/actualites/economie/cout-cancer-poumon
Le cancer du poumon est un des moins cher à traiter (car un des plus courant - donc un de ceux pour lesquels les concurrences sur les médicaments est rude.)
Egalement "seulement" 15% des fumeurs (dans l'approche la plus pessimiste) développent un cancer du poumon. On peut ajouter à celà que 15% des personnes n'ayant jamais fumé, ni fréquenté de fumeurs de façon significative, font également un cancer du poumon (N.B : une autre variante qui est plus longue et plus cher à traiter).
[^] # Re: Ne pas confondre ...
Posté par Kaane . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 8.
22'000 euros ouais… ca doit bien faire 10% du cout d'un traitement contre le cancer je pense, au maximum.
Rappel (j'en ai déjà fait plusieurs https://linuxfr.org/nodes/94279/comments/1353965 ) si toutes les taxes percues au titre des ventes de produits sur le tabac étaient reversée à la sécu on reboucherait le trou de la sécu en 3 ans.
Si on laisse la TVA de coté, il faut 5 ans.
Donc oui les taxes percues au titre du tabac compensent largement (hint tous les fumeurs ne choppent pas le cancer).
[^] # Re: égalité
Posté par Kaane . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 10.
Si elles veulent vraiment l'égalité, elles ont qu'à arrêter de chialer et se faire greffer des couilles.
(Bataille de lieux communs - je vois ton stéréotype et je relance de 100).
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 2.
a) Avec HAProxy ce sont plutot des liens 10Gb que je sature, généralement par paquet de quatre (sinon les fusion I/O se sentent inutiles)
b) Il existe déjà un excellent proxy sur-optimisé avec un controlleur très très light pour le HTTP : NGINX. Et ben tu sais quoi, il se fait battre par HAProxy au niveau perfs pures (d'un autre coté aussi il fait beaucoup plus de choses que HAProxy - et en plus on peut assez facilement les combiner c'est du bonheur)
c) Le wrapper n'existe pas encore - donc pour les benchs il va falloir attendre.
d) Parmis les benchs des trucs qui m'intéressement il y a le temps que met HAProxy à redémarrer et pour quel cout CPU - Sur cet partie du bench je peux te garantir que je pourrais faire la différence à 100% entre les deux versions même si les temps de respawn sont rigoureusement identiques. Ne serait-ce qu'en surveillant les context swap.
[^] # Re: Ils payent leur retard
Posté par Kaane . En réponse au journal AMD fait aussi le ménage. Évalué à 4.
Bof, personellement les mises à jours de firmwares, les perfs de backplane à retweaker en permanence pour cause de mise à jour de firmware, les ventilos à passer en mode "à donf" en permanence pour limiter la chauffe CPU je passe ça en case "maintenance".
De façon générale la défaillance c'est ce qui me casse les pieds mais qui ne me prend pas du temps (enfin le temps d'un cout de fil au support pour qu'ils viennent changer la pièce). La maintenance c'est ce qui mobilise un technicien ou plus pendant deux heures pour faire repartir la machine (éventuellement en mode dégradé faute de mieux).
Maintenant c'est mon vocabulaire à moi, je suis pas sur du tout que l'académie soit de mon coté sur le coup.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 5.
mais lorsque je te vois critiquer un process de contrôle pour des raisons de performances, je trouve ça quand même assez cocasse :)
Ben écoute tu le prends comme tu veux. On va juste dire que l'auteur du logiciel haproxy refuse les controlleurs pour des raisons de performances - et accessoirement il a le proxy TCP le plus rapide et le plus léger que je connaisse. Peut-être qu'il se trompe et qu'un controlleur n'aurait pas d'impact sur les perfs, en attendant et depuis dix ans, c'est lui qui tiens la position de tête au niveau proxy. Donc tout bien pris en compte, il semblerait que son choix ne soit pas idiot.
[^] # Re: Ils payent leur retard
Posté par Kaane . En réponse au journal AMD fait aussi le ménage. Évalué à 3.
A quoi sert le RVI ?
Ce sont des jeux d'instruction du processus qui permettent de faire le mapping entre la mémoire virtuelle des machines virtuelles et la mémoire virtuelle de la machine hote. La solution software (shadow pages) est souvent (beaucoup) plus lente.
mais j'aurais adoré pouvoir jouer avec un Opteron et voir ce que ça a dans le ventre.
A l'époque (4 ans) en virtualisation ca envoyait du lourd - quand ca marchait. Sur VMWare on avait des gains de perfs jusqu'à 50% sur des applis java lourde (à machine de prix comparable).
Aujourd'hui je ne sais pas. Mais je ne suis pas sur que ce soit rentable - de totue façon il y avait trop de maintenance.
[^] # Re: Ils payent leur retard
Posté par Kaane . En réponse au journal AMD fait aussi le ménage. Évalué à 3.
Par contre je me pose des questions sur la légitimité de la domination des Xeon, je n'ai jamais vu un seul serveur en Opteron.
Ben écoute, pour avori pas mal utilisé des (gros) serveurs opterons à l'époque ou les serveurs Xeon ne prenaient pas en charge le nested paging (RVI ca s'appelle maintenant), je peux te dire que je suis vraiment content que ca existe sous Xeon maintenant.
Je sais pas si le problème venait des cartes mères, des CPU eux-mêmes ou du lot de processeurs qu'on a reçu - mais on a eu un taux de pannes reccord pendant deux ans.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 4.
très pénalisant de garder un pointeur vers la config pour chaque socket d'ouverte ? ça ajoute au pire une indirection de pointeurs quand tu veux accéder aux infos.
Sur un logiciel dont le but est d'ouvrir des centaines de milliers de connexions par seconde - oui c'est pénalisant.
Ensuite il ne suffit pas d'avoir la config du socket coté proxyC ou proxyS , mais assez de metas données pour pouvoir "deviner" que la connexion sur le port TCP 12312 est une session FTP passif et que donc lorsque je vais recevoir une demande d'ouverture de port sur le 12313 par le même client, il va falloir que je l'accepte et que je le redirige vers le bon serveur en cas d'authentification etc.
Tout ceci n'est pas le boulot d'un proxy TCP. C'est éventuellement le boulot d'un routeur/firewall coeur de réseau.
[^] # Re: systemd a bon dos
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 9.
Tu balances cette phrase comme si c'était normal
Ca l'est
Bon, quand tu me demanderas d'aller à gauche, j'irai tout droit
Ben dans ce cas tu ne fais pas ce que je t'ai demandé. Quand je demande un reload et qu'un serveur fait un restart il fait ce que je lui ai demandé (ie prendre en compte la nouvelle config). Si le concepteur du logiciel estime que pour prendre en compte la nouvelle config il faut nécessairement faire un restart, il est probable qu'il ait raison.
et c'est tout à fait légitime que systemd essaye de forcer les soft à être corrigés plutôt que de permettre des bidouilles.
Non.
Le truc c'est que le reload est déjà en lui même une bidouille - bien pratique certes, mais une bidouille. C'est même une bidouille assez récente en vrai et pas mal de versions un peu ancienne des logiciels ne supportent pas le reload et/ou l'interpretent comme un restart (On parle de trucs assez mainstream, genre apache 1 ou encore sendmail) et il y a encore pas mal de paramètres de pas mal de daemons qui nécessitent de toutes les façon un restart pour être prise en compte (un simple reload ne suffisant pas).
Pour signifier le reload on utilise une autre bidouille : envoyer à un daemon un signal qui n'a rien à voir avec la choucroute. Le SIGHUP sur un daemon c'est comme un poisson avec une bicyclette, si on est pas prévenu on voit pas vraiment ce que l'un et l'autre font ensemble.
Pour systemd c'est encore une bidouille de plus : si un daemon n'a pas d'interface DBus, alors on va lui envoyer un petit SIGHUP pour lui dire de recharger sa config. Donc je ne sais rien du daemon, on a pas d'interfaces pour dialoguer ensemble, mais je vais partir des principes suivants :
a) il a une fonction reload
b) cette fonction reload peut être déclenchée par un SIGHUP
c) Mon SIGHUP sera nécessairement pris en compte et le reload fonctionnera nécessairement (on a toujours pas d'interface pour dialoguer - donc si le serveur répond "pas maintenant" ou "j'ai pas les droits sur le fichier de config" on l'a dans l'os)
d) Ca ne génèrera pas de restart du daemon
e) Accessoirement quand on fait un reload de tel ou tel processus il n'y a pas de pre ou de post traitements à faire.
Bien entendu ca marche dans 99% des cas avec des daemons relativement modernes dans des paramétrages relativement standard - mais de là à dire que c'est de la lutte contre la bidouille (alors qu'il y en a déjà trois grosses pour mettre en place cette "lutte") et que systemd peut s'accorder le droit de faire comme il veut "pour le bien de tous", permet moi d'être circonspect.
Si les démons font la différence entre reload, reload_now et force_reload (avec toutes les variantes possibles et immaginables) c'est bien que SIGHUP à la barbare ne suffit pas, chercher à l'imposer comme LA référence est idiot. (Et ce n'est d'ailleurs pas le but de systemd - le hack du SIGHUP c'est plus un mode de compatibilité qu'autre chose.)
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 3.
Il suffit pas tout simplement de binder une connextion avec une config en lecture seule et de binder les nouvelles connexions avec la nouvelle config ? Voila tu as évité ton effet de bord diabolique.
Le problèmes est que tu ne peux pas faire la différence entre la continuation d'une ancienne connexion et une nouvelle connexion "simplement".
Prend le FTP pasif comme exemple. Ou une connexion avec un tunnel. Autant tu peux suivre la connexion "au fil de l'eau" autant quand tu vas changer ton proxy (ce qui veut dire que tu vas avoir un autre processus qui va se mettre à écouter sur une plage de port) tu vas te retrouver comme un con en voyant arriver les demandes. Tu as besoin des infos qui sont dans l'ancienne appli pour t'assurer que la connexion sur le port X est nouvelle ou ancienne, connue ou inconnue. Et ca serait très pénalisant au niveau perf de faire ça.
[^] # Re: systemd a bon dos
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 3.
ça doit être bien dégueulasse le script sysV pour le coup, parce que là, même avec les cgroups, on arrive à paumer le daemon en cours de route
Euh non. Les scripts init pour haproxy font normalement tous un peu la même chose : quand on demande un reload, on se prend un restart.
C'est un choix qui a été fait, pour éviter les abus et tout les hacks sales des init sysV.
C'est bien pour ça que j'ai dit que ca n'est pas la faute de systemd non plus. Le choix de limiter le nombre de commandes dans systemctl ne me choque pas plus que ça. (Par contre l'absence de templates dignes de ce nom ou la impossibilité de faire des interactions utilisateurs pendant l'init me hérissent - mais c'est un autre débat).
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 3.
Arrête de me faire rire… le controlleur il est juste là à attendre des signaux… il n'a aucun impact sur la perf du process qui est controllé.
Il y a pas que SIGHUP dans la vie.
Les autres signaux m'interressent peut être, et peut-être que le fait de les recevoir quelques microsecondes plus tôt et sans context switch m'interresse.
Ensuite même si il ne fait que d'écouter les signaux et les rebalancer il me prend quand même de la mémoire, du CPU etc. Alors qu'il ne me sert à rien si je n'ai pas systemd.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 4.
Ici le cas c'est, je lance un nouveau process avec nouvelle config, j'attend que le vieux process arrête son travail en cours proprement et s'arrête
Sauf que ton nouveau process ne pourra pas être actif tant que l'ancien n'est pas arrété (sinon bonjour le mic-mac au niveau des sessions) et que donc tu vas perdre des connexions. Si il y a un mec qui a décidé de télécharger un projet de plusieurs Go, tu es juste bloqué pendant des heures sans pouvoir accepter de connexions.
Ou alors tu essayes de finir les sessions actives pendant un temps raisonnables (on va dire 10 secondes) mais sur un site à forte demande ca n'est pas top non plus. Et en plus tu finis quand même par fermer tout brutalement et te relancer si toutes les sessions ne sont pas closes au bout de 10sec.
La meilleure solution (en fait la seule qui soit viable) consiste à tout foutre par terre et à laisser les serveurs se démerder si ils veulent de la résistance/de la reprise de session logique. C'est d'ailleurs la solution adoptée par tout le monde (NGINX, apache mod_proxy, squid etc.)
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 3.
il suffit de faire correctement le wrapper et il sera générique
On peut effectivement faire un controlleur "light" plutôt qu'un wrapper spécifique à systemd.
Sauf que je ne vois pas pourquoi j'irais perdre des perfs avec un controlleur, alors que je cherche au contraire à en gagner le plus possible.
Problème systemd => Verrue systemd.
les autres daemons n'en ont pas besoin, preuve que c'est non-nécessaire
Tout à fait, et d'ailleurs les autres démons n'ont pas besoin de 99% de ce qu'utilise un démon pris au hasard. Preuve que les démons c'est non nécessaire.
Ou alors c'est juste qu'il y a très peu de démons en mode single processus pour qui un reload dynamique est hors de question.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 3.
Comment tu transfères une session sécurisée ?
Comment tu fais la différence entre un nouveau serveur et un serveur qui a juste changé d'IP
Comment tu prend en compte le load-balancing/le session queuing/les flags TCP ?
Comment tu réadresse tes lans/vlans ?
Comment tu notifies les clients et les serveurs de tes décisions ?
etc.
On est pas juste dans le domaine de la paresse, il faudrait uen norme complète de prise en charge des modifications de topologie aussi bien au niveau client que serveur, et un proxy avec des tables de suivi de cent pieds de long. Grosso modo ca revient à transformer le proxy en firewall/router coeur de réseau. C'est un poil overkill pour la plupart des applications non ?
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 9.
je vois pas pourquoi, c'est un choix de design
Tu peux en discuter avec le mec d'haproxy si tu veux, son design single process est actuellement le proxy le plus rapide disponible pour un cout CPU ridicule.
je vois pas ce que processus unique ou non, que ce soit un proxy ou un lecteur audio ou un livre de schtroumph y change quoi que ce soit
Une appli standard a tout intéret à conserver son état interne quelque part et à disposer en permanence de tous les éléments pour comprendre et analyser cet état.
Un proxy n'a aucun intéret à faire celà, il doit faire de la mise en relation le plus rapidement possible entre des clients et des serveurs. A partir de la une question comme "comment on en est arrivé là" ne l'interresse pas. Pour être capable de recharger dynamiquement une config un proxy devrait être capable de comprendre pour quel raison il est dans l'état présent, de réinterpréter l'état en fonction de la nouvelle config et de notifier de façon transparente le client et le serveur des décisions qu'il a prise. Sur un proxy générique comme haproxy c'est tout simplement impossible (ne serait-ce que de convaincre un autre serveur http de reprendre une session modifiée comme si c'était une des siennes ca va être coton, à moins d'en avoir rien à faire de la sécurité du bigniou).
Donc un proxy raisonnablement générique n'a pas vraiment d'autre choix que de redémarrer à chaque changement de config. Et si on doit redémarrer ET que l'on est en architecture processus unique ben paf le systemd.
Pas encore il est en cours d'écriture
Vu le chemin choisi, il n'agira pas plus mal qu'un controlleur NGINX
Pas plus absurde qu'autre chose. Sur un init classique je n'ai pas besoin de l'overhead lié à systemd - donc autant s'en passer. Surtout que généralement quand on utilise haproxy c'est que l'on veut utiliser jusqu'à la dernière goutte de CPU disponible pour créer des connexions. Personellement je serais même pour un configure --without-systemd (ce qui j'imagine dans ta vision serait encore pire).
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 6.
Tu as encore mal lu (décidément c'est récurrent), il prépare le terrain pour du code qui n'existe pas encore :
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 8.
Oups toute mes excuses allcolor, j'avais mon canon à Zenitram chargé et le coup est parti tout seul.
Faut dire que ton imitation était troublante.
Donc je retire le coté incisif et le qualificatif "personne un peu lente" de ma réponse précédente. Toutes mes excuses.
(Mai aussi… Faite gaffe les mecs avec les appeaux à trolls quand vous portez pas de gilet orange…)
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 7.
C'est quand même dingue qu'a vous lire, toute la puissance de haproxy réside dans son code de reload de config
Je réexplique pour les personnes un peu lente.
Toute la puissance d'haproxy vient du fait qu'il est à processus unique, piloté par évennement. (Single process, event driven).
Sur ce genre d'appli (un proxy en mode processus unique) il n'est pas possible de mettre à jour la config de façon dynamique. Il n'existe pas de méthode pour aglomérer intelligeament l'ancienne config et la nouvelle (les serveurs peuvent avoir changés d'ip ou de nom, certaines sessions autorisées peuvent être interdite, le poids de load balancing peut avoir été changé etc.)
A partir de la quand on modifie la config d'un proxy la seule bonne façon de faire est de tuer et de relancer les processus de proxification et de repartir à 0.
Si il y a un controlleur dédié (ie le daemon n'est pas le processus de proxification) alors le controlleur relance les processus fils un par un (c'est le cas pour nginx) mais dans le cas d'une appli à processus unique la SEULE façon de faire est de relancer complètement le processus.
A partir de là forcément il faut créer un "pseudo controlleur" pour devenir compatible avec systemd. Le "pseudo controlleur" ne fera rien d'autre que de lancer haproxy et de lui passer les messages systemes (d'ou le "pseudo").
Donc en fait : proxy+architecture à processus unique = on relance tout en cas de changement de config.
Le pseudo controlleur ne sert à rien d'autre qu'à faire plaisir à systemd d'ou le terme de wrapper.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 2.
J'aime bien : devoir adapter en faisant 10 lignes de code (et elles sont faites, tu ne perds absolument rien, on 'l'a déjà fait pour toi, comme des millions d'autres petites adaptations faites par des logiciels pour la compatibilité),
Tu as mal lu. les dix petites lignes de codes ne sont pas là pour changer le comportement de Haproxy (qui est le bon), mais pour lui permettre d'être piloté par le wrapper systemd.
Donc le démon n'est pas normalisé, il continue à fonctionner exactement comme avant, mais il a maintenant une interface de plus pour être piloté un wrapper.
[^] # Re: systemd, c'est bien
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 6.
Tu ne fais que démontrer que systemd est nécessaire, afin de forcer les daemons à être standard
Quitte à perdre au passage le proxy le plus performant disponible ?
Sans façon non.
Haproxy est un excellent proxy avec des perfs que ce soit en conso CPU ou en nombre de connexions par secondes qui sont inégalées.
Ceci est du à son architecture processus unique qui ne changera pas (et qui ne doit pas changer).
D'ailleurs la solution apportée est de créer un wrapper, pas de modifier le comportement de haproxy.
Donc non, il n'existe déjà pas de démons standards - et systemd ne va rien faire pour améliorer les choses.
[^] # Re: systemd a bon dos
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 10.
J'imagine que tu fais référence au chapitre 13.6
Si c'est bien le cas
a) Il s'agit de conventions, pas de normes. L'utilisation de sighup pour recharger la config est un hack. C'est d'ailleurs mentionné dans le texte.
b) Dans le cas d'un proxy (surtout en mode load balancing) ca n'a pas vraiment de sens de garder les process actifs vivants au moment d'un changement de config - et comme haproxy est en mode processus unique architecturalement, forcément il redémarre (d'ailleurs Nginx redémarre tous les workers en cas de changement de config, qu'il soit en mode proxy ou non)
c) Haproxy est très correctement écrit, il a des perfs monstrueuses, fonctionne sans failles connues depuis 2002, est utilisé par des milliers de serveurs à travers le monde etc.
Son architecture processus unique le rend incompatible avec systemd sans un wrapper - ca n'est ni un défaut de haproxy, ni pour le coup réellement un défaut de systemd. Ca serait mieux si on pouvait passer des commandes aux serveurs directement via systemctl (des commandes non interprétées je veux dire) mais ca n'est pas possible (cette fois par design de systemd).
[^] # Re: PEBKAC Comme d'hab...
Posté par Kaane . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 10.
Je maintiens aussi que ne pas vouloir changer ses habitudes pour utiliser Gnome3 est un PEBKAC.
Oui, enfin si changer ses habitudes ca veut dire réécrire les .desktop, remonter des bugs pour chaque .desktop mal écrit et passer en locale en_US, ben je vais pas changer mes habitudes.
Ceci dit même si j'ai essayé Gnome3/Gnome-shell, je n'ai pas vraiment insisté. J'utilise Mate et j'en suis très très content.
Mes applis Linux X11 de référence (Dia, Gimp, LibreOffice, firefox etc.) sont encore en GTK2 et les déclarations du projet Gnome au sujet de Gnome3 me donnent plutôt envie de rester le plus éloigné possible de Gnome-shell et toute la clique.
Les applis que je lance fréquamment je les envoie avec des raccourcis claviers (ce qui pose des problèmes à faire sous Gnome-shell) mes applis moins courantes sont accessibles très rapidement via des menu custom (auquel j'accède sans la souris d'ailleurs) et les applis dont je me sers rarement sont rangées dans un menu qui fait sens pour moi. Donc avant que les "améliorations" de Gnome-Shell me fassent gagner du temps il va se passer des choses. Surtout que les mises à jour Gnome-shell ont la sale manie de casser/interdire les customisations qu'on avait mis en place.
J'ai branché mon cerveau après plusieurs heures de config et de rage avec les mises à jour et je suis passé sur Mate. Depuis tout va mieux.