Par contre, ils doivent renommer le lien, ils ne testent pas. Lien en HTTP, d'ailleurs Un curl montre un GET sur la souscription, puis un redirect https vers la page de souscription. Pas très futé.
GET /subscribea/index.php?forfait=10 HTTP/1.1
Location: https://mobile.free.fr/subscribea/index.php?forfait=10
Toute la stack d'automatisation de la plateforme que je gère est codée via des recettes ansible depuis 2013. Ça va du provisioning de serveur jusqu'au build et déploiement de containers docker, en passant par la configuration de nos load balancers haproxy.
Quand awx/tower est sorti, nous avons dû faire partie de 30 pèlerins à m'avoir acheté. Nous n'avons pas renouvelé la licence tant c'était un produit inutile et cher pour ce qu'il proposait, en 2014.
Finalement nous avons remplacé tower par jenkins et les plugins qui vont bien. Ça suffit largement.
J'ai besoin d'être rassuré, là. N'y aurait-il que moi pour penser que systemd n'a quasiment aucun intérêt sur un serveur ? Sauf le fait de tout complexifier ?
Ca me rappelle quand j'ai tenté de clusteriser mon NFS avec une bascule (SAN) du /var/lib/nfs. La galère avec systemd (sources dans mon bouquin) !
... Le pire c'est tenter d'écrire un "kickstart" pour un installation automatique. Simplicité enfantine sur Redhat, le parcours du combattant sous Debian (et ubuntu).
Je te félicite, Willy, ainsi que tous les contributeurs, pour l'excellence de ce produit, et la superbe réactivité face aux échanges que certains (comme moi) ont eu avec toi (cas du include :) ).
Nous utilisons HAProxy pour des sites web, et certes, il faut prendre le temps d'appréhender le produit et sa configutation qui peut être autant simple que très complexe, mais quel bonheur de se débarrasser ainsi de matériels chers et parfois bien trop complexes (chiants) à configurer !
Nous utilisons le trio keepalived (pour le VRRP), quagga (pour OSPF) et HAProxy, le tout automatisé via ansible, et nous avons maintenant la parfaite maitrise de nos LB, de bout en bout.
Je te comprends… Sache que tu n'es pas le seul. Le dernier chronopost que j'ai envoyé à mis 17 jours pour arriver. Le plus drôle c'est qu"il a transité par la belgique, puis le Luxembourg, puis l'Allemagne pour enfin arriver au bon endroit (de France vers France). le contenu (des chocolats) est arrivé périmé.
Par contre, après deux lettres bien salées, ils m'ont remboursé (que l'envoi par contre).
May 1 18:18:00 ks354723 kernel: Node 0 DMA: 331*4kB 320*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3884kB
May 1 18:18:00 ks354723 kernel: Node 0 DMA32: 485*4kB 8*8kB 0*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3828kB
...
qui précisent le nombre de segments de la taille donnée disponibles. Si ton application a besoin d'un segment de 2048ko et qu'aucun n'est dispo, le noyau déclenchera un oom_killer même si le total disponible dépasse les 2048 ko.
Dans ton cas, la purge des caches ne libère "que" 3 Go de mémoire. Le reste n'a pas pu être libéré car il est effectivement en cours d'utilisation. Il est possible que ces 3 Go étaient utilisés et non libérables lors du déclenchement de l'OOM killer.
Ton serveur est un hyperviseur, c'est en effet embêtant qu'il tue tes VM. Cependant il semble qu'il y avait une réelle saturation dans ton cas. Quelle quantité cumulée de RAM as-tu affecté pour l'ensemble des VM ?
Te voyant mal rajouter de la RAM (tu es au taquet, limite matérielle atteinte non ?), tu devrais répartir tes VM sur d'autres serveurs. Il n'y a, je pense, mais je peux me tromper, pas grand chose d'autre à faire.
Moi ce qui m'embête, ce n'est pas le titre d'usage, mais l'utilisation du mot "expert". Notamment quand on me présente un "expert en ", ou qu'on me présente comme "expert en y".
Ça ne veut rien dire, expert, ou plutôt ça veut dire tout et n'importe quoi. Expert en Powerpoint, expert en Linux, expert en tartes flambées, expert en moulage...
Dans mon cas, c'est "expert Linux". C'est drôle ça, j'en fait depuis la première moitié des années 1990, et j'ai du mal à me considérer comme expert, car l'expertise induit une connaissance et une maîtrise quasi-parfaites du sujet. Et le sujet est bien trop vaste pour être expert sur l'intégralité du domaine. Dire qu'on a atteint un certain degré ou niveau d'expertise, OK. Mais dire qu'on est expert (à la sauce commerciale) ...
Si je peux me permettre, et avec tout mon respect, je ne suis pas totalement d'accord avec toi. Certes ceci ne présage pas du nombre de services lancés au démarrage ou de la qualité de systemd. Il faut penser au ressenti de l'utilisateur (sur son poste de travail) suite à une installation par défaut. S'il installe Ubuntu et que ça boote en 11 secondes, et qu'à côté il installe Fedora et que ça boote 2.5x plus lentement, à service final rendu égal, devine ce qu'il va choisir.
Le temps de boot n'est pas négligeable. Chez moi, avec un SSD, je vais plus vite à booter qu'à sortir de veille sur disque, d'autant plus que je coupe la multiprise à l'arrêt.
Alors si en plus sur Fedora, que je connais plutôt bien, il faut se taper n étapes de post-installation pour virer les services inutiles, rajouter les freetype qui vont bien à cause d'une histoire de brevets dont on se contrefout en Europe, etc. , le choix est vite fait.
Je serais intéressé de voir les résultats à services démarrés identiques, par contre.
Quand à systemd, et idem pour upstart, sur un serveur le gain de vitesse est assez négligeable, vu que les gros services de type Oracle par exemple, sont très long à démarrer, et que souvent des ordonnanceurs prennent le relais. Sans compter l'adaptation des lanceurs, que nous avons multi plateformes ici. Nous sommes encore très content avec notre init System V classique :)
Tes propos sont très vexants. Tu ne me connais pas. Tu devrais te renseigner sur les gens qui postent avant de répondre, surtout que je n'utilise pas de pseudo. Tu apprendrais, entre autres, que je diffuse très largement, de par mon métier, mes écrits et mes cours, l'histoire d'Unix et que je vante le travail des fondateurs (sans oublier Rudd Canaday, Brian Kernighan et bien d'autres).
[^] # Re: Mais noooon !!!
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Mémoires vives ("Permanent record") par Edward Snowden. Évalué à 10.
J'ai cliqué... :-)
# Obligation ?
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Vente forcée chez Free. Évalué à 10.
On t'oblige à souscrire ?
Non.
Donc, on ne t'a rien vendu.
Par contre, ils doivent renommer le lien, ils ne testent pas. Lien en HTTP, d'ailleurs Un curl montre un GET sur la souscription, puis un redirect https vers la page de souscription. Pas très futé.
# Proverbe du jour
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal IBM achète Red Hat. Évalué à 3.
Là où IBM passe, l'informatique trépasse
(ça sent le vécu)
[^] # Re: Les UUID, l'idéal... pour rendre illisible un fstab.
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Monter une partition - Merci Gnome !. Évalué à 8.
Je suis heureux de l'apprendre. Moi qui utilisais LVM sur Solaris, HPUX et AIX...
# Très déçu par tower
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Ansible Tower passe OpenSource. Évalué à 6.
Toute la stack d'automatisation de la plateforme que je gère est codée via des recettes ansible depuis 2013. Ça va du provisioning de serveur jusqu'au build et déploiement de containers docker, en passant par la configuration de nos load balancers haproxy.
Quand awx/tower est sorti, nous avons dû faire partie de 30 pèlerins à m'avoir acheté. Nous n'avons pas renouvelé la licence tant c'était un produit inutile et cher pour ce qu'il proposait, en 2014.
Finalement nous avons remplacé tower par jenkins et les plugins qui vont bien. Ça suffit largement.
# Change de nom !
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Publication de la première version de fwtchrq.. Évalué à 10.
Salut, j'interviens rarement, mais à mon humble avis, rien qu'à cause du nom personne ne se rappellera de ta commande, aussi bonne soit-elle...
[^] # Re: Intérêt sur un serveur ?
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, parties 3, 4 et 5. Évalué à 1.
Enfin un qui m'a compris :-)
# Intérêt sur un serveur ?
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, parties 3, 4 et 5. Évalué à -10.
J'ai besoin d'être rassuré, là. N'y aurait-il que moi pour penser que systemd n'a quasiment aucun intérêt sur un serveur ? Sauf le fait de tout complexifier ?
Ca me rappelle quand j'ai tenté de clusteriser mon NFS avec une bascule (SAN) du /var/lib/nfs. La galère avec systemd (sources dans mon bouquin) !
# C'est pas le pire ...
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 0.
... Le pire c'est tenter d'écrire un "kickstart" pour un installation automatique. Simplicité enfantine sur Redhat, le parcours du combattant sous Debian (et ubuntu).
# Félicitations !
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche HAProxy 1.5. Évalué à 4.
Je te félicite, Willy, ainsi que tous les contributeurs, pour l'excellence de ce produit, et la superbe réactivité face aux échanges que certains (comme moi) ont eu avec toi (cas du include :) ).
Nous utilisons HAProxy pour des sites web, et certes, il faut prendre le temps d'appréhender le produit et sa configutation qui peut être autant simple que très complexe, mais quel bonheur de se débarrasser ainsi de matériels chers et parfois bien trop complexes (chiants) à configurer !
Nous utilisons le trio keepalived (pour le VRRP), quagga (pour OSPF) et HAProxy, le tout automatisé via ansible, et nous avons maintenant la parfaite maitrise de nos LB, de bout en bout.
Encore merci !
# Merci
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Préservation du jeu vidéo. Évalué à 1.
Merci Kekun pour cet excellent article. Rien d'autre à ajouter.
# Ouais tous dans la rue !
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Éteins la lumière dans le couloir !. Évalué à 10.
Enfin un journal qui dénonce grave !
# LOL !
Posté par Sébastien Rohaut (site web personnel) . En réponse au message CDD long à Marseille : Technicien réseau pour test de fonctionnalités de produit sur linux embarqué. Évalué à 3.
Tout est dans le titre…
# Patience
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Wayland 0.95 est sorti !. Évalué à 4.
Si ça fait comme pour le noyau, il s'est passé deux ans entre le 0.95 et le 1.0.
# Chronopost => pedalopost
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Chez Chronopost, vos colis urgents arrivent dans 4/5 jours. Évalué à 3.
Je te comprends… Sache que tu n'es pas le seul. Le dernier chronopost que j'ai envoyé à mis 17 jours pour arriver. Le plus drôle c'est qu"il a transité par la belgique, puis le Luxembourg, puis l'Allemagne pour enfin arriver au bon endroit (de France vers France). le contenu (des chocolats) est arrivé périmé.
Par contre, après deux lettres bien salées, ils m'ont remboursé (que l'envoi par contre).
# C'est bien, ça !
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche dfc(1): une alternative à df(1) apportant couleur et graphe. Évalué à 2.
J'aime bien ce truc, un peu dans la lignée de glances. Bon travail.
[^] # Re: Détails ?
Posté par Sébastien Rohaut (site web personnel) . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1.
Je pensais à des entrées de ce genre :
May 1 18:18:00 ks354723 kernel: Node 0 DMA: 331*4kB 320*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3884kB
May 1 18:18:00 ks354723 kernel: Node 0 DMA32: 485*4kB 8*8kB 0*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3828kB
...
qui précisent le nombre de segments de la taille donnée disponibles. Si ton application a besoin d'un segment de 2048ko et qu'aucun n'est dispo, le noyau déclenchera un oom_killer même si le total disponible dépasse les 2048 ko.
Dans ton cas, la purge des caches ne libère "que" 3 Go de mémoire. Le reste n'a pas pu être libéré car il est effectivement en cours d'utilisation. Il est possible que ces 3 Go étaient utilisés et non libérables lors du déclenchement de l'OOM killer.
Ton serveur est un hyperviseur, c'est en effet embêtant qu'il tue tes VM. Cependant il semble qu'il y avait une réelle saturation dans ton cas. Quelle quantité cumulée de RAM as-tu affecté pour l'ensemble des VM ?
Te voyant mal rajouter de la RAM (tu es au taquet, limite matérielle atteinte non ?), tu devrais répartir tes VM sur d'autres serveurs. Il n'y a, je pense, mais je peux me tromper, pas grand chose d'autre à faire.
# Détails ?
Posté par Sébastien Rohaut (site web personnel) . En réponse au message OOM Killer, avec la moitié de la RAM utilisé par le cache. Évalué à 1. Dernière modification le 06 janvier 2012 à 12:16.
Peux-tu préciser si tu es en 32 ou 64 bits ? (oui, un Kernel 32 bits Hugemem ou PAE gère 64Go).
EnSeules les données actuellement inutilisées peuvent être libérées du cache. Tu peux tenter un :
sync ; echo 3 > /proc/sys/vm/drop_caches
pour voir si tu as une grosse différence avant/après. Si tu en as peu, alors tes processus utilisent actuellement le cache.
Il se peut aussi que la qté de RAM pouvant être libérée ne suffise pas. Notamment, il faudrait le détail de l'oom killer (zone normal/high/dma, etc.).
# Et "expert" ?
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal De l'utilisation contemporaine des titres honorifiques.. Évalué à 2.
Moi ce qui m'embête, ce n'est pas le titre d'usage, mais l'utilisation du mot "expert". Notamment quand on me présente un "expert en ", ou qu'on me présente comme "expert en y".
Ça ne veut rien dire, expert, ou plutôt ça veut dire tout et n'importe quoi. Expert en Powerpoint, expert en Linux, expert en tartes flambées, expert en moulage...
Dans mon cas, c'est "expert Linux". C'est drôle ça, j'en fait depuis la première moitié des années 1990, et j'ai du mal à me considérer comme expert, car l'expertise induit une connaissance et une maîtrise quasi-parfaites du sujet. Et le sujet est bien trop vaste pour être expert sur l'intégralité du domaine. Dire qu'on a atteint un certain degré ou niveau d'expertise, OK. Mais dire qu'on est expert (à la sauce commerciale) ...
Ça ne vous gène pas vous ?
[^] # Re: Un peu de nerfs dans la critique ? OK !
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal Comparatifs des temps de boot Fedora16 / Ubuntu 11.10. Évalué à 6.
Si je peux me permettre, et avec tout mon respect, je ne suis pas totalement d'accord avec toi. Certes ceci ne présage pas du nombre de services lancés au démarrage ou de la qualité de systemd. Il faut penser au ressenti de l'utilisateur (sur son poste de travail) suite à une installation par défaut. S'il installe Ubuntu et que ça boote en 11 secondes, et qu'à côté il installe Fedora et que ça boote 2.5x plus lentement, à service final rendu égal, devine ce qu'il va choisir.
Le temps de boot n'est pas négligeable. Chez moi, avec un SSD, je vais plus vite à booter qu'à sortir de veille sur disque, d'autant plus que je coupe la multiprise à l'arrêt.
Alors si en plus sur Fedora, que je connais plutôt bien, il faut se taper n étapes de post-installation pour virer les services inutiles, rajouter les freetype qui vont bien à cause d'une histoire de brevets dont on se contrefout en Europe, etc. , le choix est vite fait.
Je serais intéressé de voir les résultats à services démarrés identiques, par contre.
Quand à systemd, et idem pour upstart, sur un serveur le gain de vitesse est assez négligeable, vu que les gros services de type Oracle par exemple, sont très long à démarrer, et que souvent des ordonnanceurs prennent le relais. Sans compter l'adaptation des lanceurs, que nous avons multi plateformes ici. Nous sommes encore très content avec notre init System V classique :)
[^] # Re: Les génies sont ceux qui ne manquent pas
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 5.
C'est beau...
[^] # Re: Respect...
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 10.
Il n'y a pas de mal, je me suis emporté un peu vite. Mes excuses de mon côté aussi.
# Commentaire de Libé
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 5.
J'ai contacté Libé ce matin pour savoir s'ils comptaient en parler. Ils m'ont répondu ce soir. C'est chose faite. Et c'est original.
http://www.ecrans.fr/Deces-de-Dennis-Ritchie-printf,13393.html
[^] # Re: Respect...
Posté par Sébastien Rohaut (site web personnel) . En réponse à la dépêche Dennis Ritchie, un père d’UNIX, nous a quittés. Évalué à 0.
Tes propos sont très vexants. Tu ne me connais pas. Tu devrais te renseigner sur les gens qui postent avant de répondre, surtout que je n'utilise pas de pseudo. Tu apprendrais, entre autres, que je diffuse très largement, de par mon métier, mes écrits et mes cours, l'histoire d'Unix et que je vante le travail des fondateurs (sans oublier Rudd Canaday, Brian Kernighan et bien d'autres).
[^] # Re: Google Calendar
Posté par Sébastien Rohaut (site web personnel) . En réponse au journal KDEPIM + akonadi: Bien ou à chier ?. Évalué à 3.
Ah MERCI !!!!!!!