Encore une fois, tu emets des jugements péremptoires. Évidemment du Intel, c'est ce qu'il y a de plus compétitif en ce moment même.
20 k€, c'est pas le ticket d'entrée, c'est une machine dual-core avec 128Go de RAM. Le ticket d'entrée est à $6,000 chez IBM pour un POWER7+ 4C à 3.6 Ghz avec 8G de RAM. Oui, c'est toujours plus cher que du Intel, mais environ 1.5-2x toujours. Reste à voir ce que vaut l'architecture power sur ta workload. Je pense que faut vraiment éviter les jugements à l'emporte pièce style telle techno est mauvaise. Ça dépend du rapport prix/performance en fonction du domaine d'application.
Tyan a récemment proposé un serveur POWER avec un ticket d'entrée à $2,700 avec 4Go de RAM. On verra comment l'offre va se développer à l'avenir.
Pour ARM sur le serveur, ça fait des années qu'on en parle, mais jusqu'ici c'est pas très probant. On commence à avoir des puces puissantes dans les smartphones, elles vont bien finir par arriver dans les serveurs. D'autant que le ratio performance/consommation des puces ARM est quand même très bon.
En tous le fait que les architectures POWER (en 64 bits little endian) et ARM fassent leur entrée dans Debian montre qu'on risque d'entendre parler à l'avenir.
Pour prendre une vrai place, il faut que cela soit au même prix, IBM a toujours été hors de prix.
En fait, c'est pas si hors de prix que ça :
IBM Power System S822 - POWER8 2x10C 3.4Ghz 128GB RAM - $21,570
C'est environ 1.5x a 2x le prix d'une configuration Intel équivalente (encore que sur du Intel, ça va être compliqué de faire du 10 cœurs à 3.4Ghz, la fréquence sera surement un peu moindre). Reste que si sur ta workload, l'architecture POWER8 se comporte 2x mieux, ça revient moins cher. D'autant qu'on devrait voir apparaitre des solutions non-IBM à base de processeur POWER avec la fondation OpenPOWER.
Bon j'explicite parce que ça n'a pas l'air clair : Service Pack 1. C'est une dénomination typique des versions de Windows. Ubuntu utilise un troisième chiffre dans son numéro version : 14.04.1, et non pas 14.04 SP1.
Oui, oui, comme OS, Dell vous propose une Ubuntu 14.04 Service Pack 1. Faut croire qu'ils ont pas trop l'habitude vendre autre autre chose que du Windows.
J'ai pas lu complètement le premier article, mais le second explique exactement ce que je disais (utilisation du pipeline, latence mémoire).
Bien sûr, 4 thread / core n'équivaut pas à 4 cores mais on peut s'en approcher pas mal selon les cas.
Dans le deuxième article, ils revendiquent un facteur 1.5-2 au mieux, pas un facteur 4.
J'avais dit 1.15-1.25, on peut atteindre 2 sur une workload favorable (ils parlent de transaction donc des trucs qui font pas d'accès mémoire et qui restent en repos sur des verrous).
Mais vraiment, le SMT/HT ne vaut pas du tout un cœur physique. On essaye de nous faire croire ça en parlant de "threads" processeur, mais c'est du marketing.
Non mais sérieusement ! Tu essayes de justifier l'injustifiable.
Il serait plus logique d'annoncer la couleur dès le début, mais comme le presta rêve de CDI ben on lui file une espoir de CDI. Ne serait-ce pas mieux de pouvoir dire honnêtement que c'est 6 mois? Disons que pour le moment être honnête n'est pas rentable, les gens étant plus motivés à baisser leur salaire si il y a les 3 lettres magiques.
Ben en fait on peut tout à fait annoncer directement que c'est 6 mois. Ça s'appelle un CDD. Tout simplement. Et je vois pas pourquoi un mec qui accepte un CDD (pour X raisons, ça peut aussi être plus pratique pour lui) serait moins motivé à faire son travail. Y'a tout à fait possibilité de proposer des compensations intéressantes (salaire, primes, conditions de travail etc.). Si quelqu'un travaille pour moi, il faut que je lui propose une compensation qui lui paraisse équitable. Oh mon dieu, quelle horreur ! Parce que le CDI, ça fait partie de la compensation, on accepte un salaire moindre en échange de stabilité etc. Dire qu'on va donner un truc et ne pas le faire après, c'est malhonnête. Et injustifiable.
Etre honnête c'est moins rentable ? Sans blague…
Pis bon, même légalement, tout ça est très très borderline. Parce que dans un CDD, la cotisation d'assurance est majorée. Mais forcément, c'est moins rentable de payer pleinement les cotisations, vaut mieux faire des CDD déguisés en CDI. C'est plus rentable.
Si c'est juste la rentabilité qui compte, j'ai quelques suggestions pour les salariés lésés :
Installez un botnet sur les postes de l'entreprise qui vous accueille et louez-le. C'est pas très honnête mais c'est rentable.
Defacez le site de la société et proposez une prestation de sécurisation. C'est pas très honnête mais c'est rentable.
Subtilisez des documents confidentiels et monnayez la revente d'informations. C'est pas très honnête mais c'est rentable.
C'est juste un mode de travail qui évolue (penser qu'avant on avait un dédié hébergé chez soit, et maintenant on ne jure plus que par des VM en Cloud, ben la c'est pareil : la flexibilité amène plus de business en fait)
Ok. Vraiment ok. Tu viens de comparer un humain à un serveur/une VM, ou c'est juste moi ?
Le ratio perf/whatt n'est pas si en désavantages de Intel, vu le niveau de perf des puces à 100w.
Complètement d'accord avec ça. En prenant tout en compte (mémoire, stockage, alimentation, réseau etc.), je suis pas du tout convaincu que de l'ARM soit plus efficace énergétiquement que du Intel.
Attention la performance des Atom basés sur l'architecture Silvermont est très supérieure à celle des Atom basés sur les architectures précédentes. En particulier, les Atom Silvermont (modèles commençant par C, e.g. C2750) ne sont pas des processeurs in-order, ce qui amène de très gros gains de performance.
Sans stockage du tout, c'est mettre une pression dingue sur le réseau.
Apparemment, c'est ce que online a fait. Quand j'avais testé (pendant la phase bêta), le stockage était accédé via un network block device. La latence était d'environ 1 ms et le débit de 50 Mo/s.
Je suis d'accord avec ta remarqué sur la pression réseau. D'ailleurs ceux qui se souviennent des RPS de chez OVH et deux leur stockage iSCSI le savent bien. À voir donc si la performance de la plateforme se dégrade avec beaucoup d'utilisateurs.
Autre hypothèse, je crois que les SoC Marvell Armada disposent de deux interfaces ethernet chacun, peut-être qu'ils on un lien réseau dédié stockage.
Oui, d'ailleurs, c'est exactement ce que Online a fait : https://www.scaleway.com/features. Ils sont pas a des centaines, mais l'idée est la.
Par contre, la dernière fois que j'avais testé, le stockage était accédé via la réseau, chaque SoC n'a donc pas son stockage dédié.
Appli monothread ==> gros cache L3 et L4 & fréquence élevée, donc de grandes chance que ce soit plus performant
Éventuellement un gros cache L3/L4 ça peut aider dans certains cas particuliers (genre bases de données et join). Pour la fréquence plus élevée, ça aidera inconditionnellement, mais c'est pas forcément bon pour le ratio performance/watt. À fréquence équivalente, je sais pas si du POWER fait mieux que de l'Intel. J'imagine qu'il faut benchmarker en fonction des applications pour voir ce qui se comporte le mieux.
Appli multithread ==> 96 threads sur p8, donc plus de slot disponible pour la montée en charge (à condition que l'appli "scale" bien…)
Le POWER8 a 12 cœurs, ce qui signifie qu'a un instant donné 12 threads s'exécutent en même temps. Le Xeon en a 18, ce qui signifie qu'a un instant donné 18 threads s'exécutent en même temps.
Faut pas tomber dans le panneau de cette dénomination de "threads" processeurs et imaginer que 96 threads s'exécutent en même temps. Le 8 threads/cœur veut juste dire que chaque cœur a 8 jeux de registres et donc qu'un cœur peut switcher entre 8 threads sans faire d'accès mémoire. Mais à un instant donné, on a 1 thread par cœur qui s'exécute. Le SMT (Simultaneous MultiThreading) ou l'HyperThreading (HT) permet juste de (1) assurer que le pipeline des processeurs est bien rempli et (2) éviter la latence mémoire au moment d'un context switch.
Par exemple, en pratique, sur du Intel, l'HT (2 threads/cœur) amène un gain de 25% de performance au mieux. C'est souvent 10-15% voire même 0 sur des applications déjà optimisées.
Merci pour le reste de ton commentaire (slicing hardware des cœurs CPU, compression mémoire, hyperviseur), je connaissais pas du tout ça. Effectivement, ça fait pas mal de fonctionnalités utiles pour bien consolider, qu'on trouve pas sur du Intel.
Il n'y a que le POWER8 qui soit bi-endianess parmi les puces POWER.
Exemple : les POWER7 / POWER7+ ne le sont pas.
Je n'ai pas eu de serveurs POWER entre les mains à l'exception de VMs Runabove (POWER8), donc je ne remets pas ton expérience en cause.
Cependant, d'après Wikipedia, ils semblent que les POWER7 implémentent le jeu d'instructions PowerISA 2.06. Et d'après la documentation PowerISA 2.06, il semblerait que les POWER7 permettent d'adresser la mémoire en big/little endian, voir les sections Book I.1.9 "Storage Addressing" et Book II.1.6.5 "Endianness". Bon après, c'est juste des informations théoriques, je ne sais pas comment ça marche en pratique.
Je t'invite tout de même à consulter ces slides sur ce que propose "l'alternance" : […] Bien évidemment, il ne faut pas prendre pour argent comptant tout ce qui est écrit car un fournisseur annonce toujours que ses produits sont les meilleurs.
Oui, on est bien d'accord sur ta dernière remarque. D'ailleurs il y a du bon gros Vendredi dans les slides que tu as linké, merci :P :
J'adore la slide 7 ou on apprend que la performance d'un cœur de Haswell (récent) est moindre que la performance d'un cœur de Sandy Bridge (plus ancien). Sauf qu'ils ont pris un Sandy Bridge à 2.9 Ghz et un Haswell à 2.3 Ghz. Comment dire…
J'aime beaucoup aussi la slide 6 qui compare le nombre de "threads" des processeurs, ce qui est en général peu pertinent en termes de performance. 36 threads pour un Haswell, avec 2 threads/cœur et 96 threads pour un POWER8, avec 8 threads/cœur. Du coup d'un côté on a 18 cœurs vs 12. Je sais quel processeur va être plus performant (enfin à fréquence équivalente).
Si on compare les slides 8 et 7, on voit qu'un cœur de POWER7+ à 4.20 Ghz fait a peine mieux qu'un cœur de Xeon à 2.9 Ghz. En termes de performance/watt, c'est pas très bon, et d'ailleurs pas très rassurant sur l'architeture.
Pour y'a quand même des points forts, notamment au niveau de la bande passante mémoire (65Go/s sur un Xeon et 200-400 Go/s sur un POWER8). Peut-être que le SMT à 8 threads/cœur apporte également un gain sur certaines workload.
Personnellement, je suis pas rassuré de voir le marché mondial des processeurs serveurs aux mains d'une seule boite, donc les alternatives m'intéressent. Mais faut quand même reconnaître que les générations actuelles de Xeon sont très performants…
En effet, il n'est pas rare de voir se multiplier dans les datacenters des grilles pains/pizzas x86 avec beaucoup de core dormants, où le taux d'utilisation moyen est de 20-30% alors que sur Power on oscille plutôt dans les 80% car on consolide plus et plus facilement.
Ça chauffe pas tant que ça un Xeon de nos jours donc grille pain ça semble exagéré quand même. Surtout en face de POWER cadencés à 4+ Ghz, ça doit être autre chose le refroidissement.
C'est quoi les fonctionnalités des POWER qui permettent de consolider mieux que sur du Intel (c'est une vrai question, j'en sais rien) ?
Je sais pas si on s'est bien compris, je ne suis pas contre le RAID hard inconditionnellement. Notamment, les caches présents sur certaines cartes peuvent apporter des gains de performances sur certaines workload.
Je disais juste de faire attention avec les cartes RAID bas de gamme, elles ont souvent de mauvaises performances (inférieures au RAID logiciel…) et causent plus de problèmes qu'elles n'en résolvent. En particulier, j'ai déjà eu des problèmes en RAID5 avec des H310.
Comme règle approximative, si c'est pour acheter une carte RAID sans cache, autant faire du RAID logiciel.
Oulà non, de manière générale, il faut fuir les cartes RAID bas de gamme comme la peste. En particulier, on a déjà eu de GROS problèmes de performance avec la H310 en particulier sur du RAID5, et on est pas le seuls apparemment :
Pour ioping, tu as les même résultats sur l'ancienne et la nouvelle machine, ~160Mo/s en lecture et ~75 IOPS dans les deux cas, ce qui correspond à des performances normales.
Je vais essayer de regarder tes résultats iozone, c'est toujours difficile à interpréter. Mais effectivement, y'a de sacré différences entre tes deux machines, et la différence de performance de MYSQL vient sûrement de là. Probablement la carte RAID de l'ancienne machine aidait vraiment.
Pour avoir des résultats plus faciles à interpreter dans un premier temps, tu peux faire des tests avec ioping en écriture (ioping -W) mais lis la page de man avant pour ne pas perdre de données.
Pour ce que est de la configuration, j'irais jeter un œil du côté de readhead, désactivation du NCQ etc. plutot que dans la configuration de MySQL.
Une autre hypothèse à vérifier si tu as des disques avec des secteurs 4k sur la nouvelle machine (Advanced Format 512e etc.) : est-ce que mdadm ne fait pas n'importe quoi au niveau de l'alignement du RAID ?
Avant de faire des corrections/réglages, j'aime bien avoir identifié de manière certaine la cause du problème de performance. T'as déjà fait des tests pertinents (hdparm, écriture RAM->disque), qui permettent déjà d'éliminer des causes probables de problèmes de performance.
Un truc me fait cependant tiquer. Sur les deux machines, l'écriture se fait à ~30 Mo/s pendant la restauration d'une sauvegarde. C'est étrange parce que si la restauration prend deux fois moins de temps sur une machine que sur l'autre, on s'attendrait à ce qu'une machine écrive 2 fois moins vite que l'autre (grosso modo).
Pour voir ce qu'il se passe exactement, tu peux mesurer la vitesse d'écriture disque pendant les 8h ou 14h de la restauration de la sauvegarde. Le plus simple est de bidouiller avec iotop : Measure I/O over time
S'il te reste du temps, je pense qu'il serait utile de tester la performance en termes d'IOPS des deux machines :
ioping
$ ioping -RL /dev/md4 # Débit en lecture
$ ioping -R /dev/md4 # IOPS en lecture Idéalement, il faudrait lancer ces deux tests "à vide" et pendant la restauration d'une sauvegarde. Tu peux aussi faire quelques tests en écriture avec ioping (4k, 128k, 1M, 16M, 128M par exemple).
iozone
$ iozone -a # Tous test iozone (write, read, reread, rewrite) Ça te permettra de caractériser plus précisément la performance du système de stockage des deux machines.
la ventilation d'un retrait de liquide au distributeur,
ben c'est une depense sans affectation, puisque c'est un seul DEBIT de 40euros.
Moui, mais je voudrais me souvenir de ce que j'ai fait avec les 40 euros. Je claque ~90€/mois en liquide mais j'ai aucune idée de ce que j'en fais. Et comme je fais mes comptes une fois tous les trois mois, je m'en souviens jamais. Clairement si je claque 90€/mois au bar, faut que je me calme. Si par contre c'est de la bouffe, je peux pas y faire grand chose.
evidemment avec ce tableau je n'ai pas des jolis graphes pour savoir que je passe 30% de mon salaire en logement, que ce mois ci j'ai passé 40% en restau, et que les impots me prennent 20%, mais ca, en fait, je m'en fous un peu.
Pas moi. C'est précisément ce qui m'intéresse, mais c'est trivial à faire sur un tableur une fois qu'on a les données. Une pivot table, deux trois average(), un graphique et ça roule.
Mon problème, c'est vraiment de pouvoir ventiler les données.
J'utilise un tableur pour l'instant, mais c'est chiant de tout classer à la main, fusionner à la main le fichier téléchargé depuis le site de ma banque etc. J'utiliserait bien une application de compta, mais c'est à peine plus pratique que le tableur.
Si j'étais un vendeur de voiture, et que je devais estimer le nombre d'acheteurs qui font de la conduite sportive sur circuit par rapport au nombre susceptible de faire des excès de vitesse sur les routes nationales, j'aurais limité tous mes modèles à 130 km/h.
Ça n'est vraiment pas acceptable qu'un FAI interdise (ou empêche grandement) l'envoi de mail à partir d'une connection internet. D'autant plus que là, il n'y a vraiment pas de vies en danger.
Si on veut combattre le Spam, y'a une solution toute simple : Le FAI désactive l'envoi de mails par défaut, et laisse une option à activer dans une interface d'administration pour le pourcent de geek qui veut héberger son mail.
Nan, parce jusqu'à preuve du contraire, on lui a vendu un accès internet, et on est pas censé lui dicter quoi faire avec.
Mais ce que tu proposes c'est d'héberger ses données dans des sociétés à l'autre bout du monde. et là je dis STOP.
S'indigner, c'est bien. Lire le journal, c'est mieux…
Je parle justement des problèmes de l'auto-hébergement sur un serveur personnel dans le journal. Et je sais pas ou tu as vu que je proposais de mettre mes données chez Google. Je pars justement du constat que beaucoup de gens le font et que ce n'est pas souhaitable.
Pour cette mode des applications smartphone, tu as raison, depuis quelques années la mode est à l'installation d'applis natives. Je pense que ça tient à la faisabilité technique (et pas au fait que les gens sont idiots…). Par exemple, c'est facile de faire une appli qui accède au micro, à la cam, au GPS, c'est plus difficile en web. Même chose, c'est facile de faire des applications qui répondent au gestures (swipe, pinch to zoom etc.), en web c'est plus compliqué. Même chose, je suppute que les bibliothèques graphiques sont plus faciles à utiliser pour faire des applications natives que les bibliothèques graphiques pour faire du Web (même si ça change, hello WebComponents). Peut-être aussi à la réactivité sur les téléphones les plus anciens. Une application en Java, c'est plus rapide qu'un truc en JS.
Pour Google Maps, par exemple, moi je suis content de pouvoir utiliser le GPS de mon téléphone. Également l'application native me permet de zoomer plus facilement.
Une autre réponse que je voulais apporter à ta question, c'est que tu utilises une interface native pour accéder à un service Web, ça ne change pas grand chose. Tu est toujours en train d'utiliser un service Web.
Par exemple, quand tu utilises Dropbox (ou Google Drive), tu utilises peut-être l'application native Dropbox. Mais tu utilises aussi le côté serveur de Dropbox, sur lequel tu mets tes données d'ailleurs.
Mon problème est que je ne veux pas utiliser le service Dropbox, parce que je veux garder mes données et ne pas les filer à une entité tierce. Je veux un service qui fasse comme Dropbox (parce que la synchro et la collaboration, c'est pratique), mais que j'installe moi-même sur une machine que j'administre moi-même pour garder la maîtrise de mes données.
Tu me répondras que je peux utiliser Owncloud (et c'est vrai). Je trouve que ça reste un peu chiant à installer, il faut que j'installe le paquet, que je configure nginx et php-fpm, que je vérifie que ma config est bien sécurisée. Pour moi c'est pas trop un gros problème, mais je trouverais ça bien que tout le monde puisse installer owncloud facilement, et arrête qu'ils arrêtent d'utiliser Dropbox par la même occasion.
Je globalement très d'accord avec ta remarque, et j'ajouterais que la majorité de la population utilise uniquement des applications simples : client mail, messagerie, traitement de texte etc.
Encore que pour les jeux vidéos, je ne suis pas sur. Nvidia bosse déjà sur des solutions dites de Gaming as a service. L'idée est que le rendu du jeu vidéo se fasse sur le serveur et soit streamé sous forme de vidéo. Pour l'instant, y'a encore des problèmes de latence.
Peut-être que ça marchera, peut-être que ça ne marchera jamais. Ça aurait quand même de bon côtés : pour les LAN parties, pas besoin de faire attention à installer la même version du jeu sur tout les postes. D'ailleurs pas d'install du tout, pas de téléchargement de mises à jour de 14Go avant de jouer. On clique et le jeu se lance. Au niveau facturation aussi, on peu imaginer un service d'abonnement où pour un abonnement mensuel donné, on a accès à toute une bibliothèque de jeux…
Personnellement, je ne suis pas dans le déni, je suis simplement un observateur extérieur à tout ça, pas concerné par ces sujets
Évidemment, si tu n'utilises pas du tout d'applications Web, tu peux te sentir "pas concerné" par tout ça. Tout comme les utilisateurs d'applications en ligne de commande sont pas tellement concernés par ce qui se passe dans le domaine des interfaces graphiques.
Mais quand même, tu auras remarqué qu'il y a un grand nombre de tes contacts qui utilisent des applications Web, que ce soit Facebook, Gmail ou Google Docs. Et ça pose des problèmes de maîtrise de ses données personnelles. En tant que "geek" (ou au moins personne qui comprend l'informatique), je me sens un peu obligé de "montrer la bonne voie" pour garder la maîtrise des ses données.
Et clairement, je ne peux pas opposer LibreOffice à Google Docs. La possibilité de travailler en temps réel à plusieurs est ce qui attire dans ces plateformes. Aussi le fait qu'ils n'ont pas besoin d'aller télécharger et installer un logiciel. Je voudrais pouvoir proposer WebODF par exemple, mais ce genre d'applications Web reste chiant à installer, même pour quelqu'un qui maîtrise un peu l'informatique.
[^] # Re: Power et little endian
Posté par X345 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 3.
Encore une fois, tu emets des jugements péremptoires. Évidemment du Intel, c'est ce qu'il y a de plus compétitif en ce moment même.
20 k€, c'est pas le ticket d'entrée, c'est une machine dual-core avec 128Go de RAM. Le ticket d'entrée est à $6,000 chez IBM pour un POWER7+ 4C à 3.6 Ghz avec 8G de RAM. Oui, c'est toujours plus cher que du Intel, mais environ 1.5-2x toujours. Reste à voir ce que vaut l'architecture power sur ta workload. Je pense que faut vraiment éviter les jugements à l'emporte pièce style telle techno est mauvaise. Ça dépend du rapport prix/performance en fonction du domaine d'application.
Tyan a récemment proposé un serveur POWER avec un ticket d'entrée à $2,700 avec 4Go de RAM. On verra comment l'offre va se développer à l'avenir.
Pour ARM sur le serveur, ça fait des années qu'on en parle, mais jusqu'ici c'est pas très probant. On commence à avoir des puces puissantes dans les smartphones, elles vont bien finir par arriver dans les serveurs. D'autant que le ratio performance/consommation des puces ARM est quand même très bon.
En tous le fait que les architectures POWER (en 64 bits little endian) et ARM fassent leur entrée dans Debian montre qu'on risque d'entendre parler à l'avenir.
[^] # Re: Power et little endian
Posté par X345 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 3.
En fait, c'est pas si hors de prix que ça :
IBM Power System S822 - POWER8 2x10C 3.4Ghz 128GB RAM - $21,570
C'est environ 1.5x a 2x le prix d'une configuration Intel équivalente (encore que sur du Intel, ça va être compliqué de faire du 10 cœurs à 3.4Ghz, la fréquence sera surement un peu moindre). Reste que si sur ta workload, l'architecture POWER8 se comporte 2x mieux, ça revient moins cher. D'autant qu'on devrait voir apparaitre des solutions non-IBM à base de processeur POWER avec la fondation OpenPOWER.
Apparemment le processeurs ARM dans le Moonshot a des performances médiocres : http://www.anandtech.com/show/8357/exploring-the-low-end-and-micro-server-platforms/9
A voir comment ça évolue dans les années à venir.
[^] # Re: Ubuntu 14.04 SP1
Posté par X345 . En réponse au journal Le Dell xps 13 édition développeur est enfin là. Évalué à 10. Dernière modification le 11 avril 2015 à 00:18.
Bon j'explicite parce que ça n'a pas l'air clair : Service Pack 1. C'est une dénomination typique des versions de Windows. Ubuntu utilise un troisième chiffre dans son numéro version : 14.04.1, et non pas 14.04 SP1.
# Ubuntu 14.04 SP1
Posté par X345 . En réponse au journal Le Dell xps 13 édition développeur est enfin là. Évalué à 10. Dernière modification le 10 avril 2015 à 23:42.
Oui, oui, comme OS, Dell vous propose une Ubuntu 14.04 Service Pack 1. Faut croire qu'ils ont pas trop l'habitude vendre autre autre chose que du Windows.
[^] # Re: Power et little endian
Posté par X345 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 3.
J'ai pas lu complètement le premier article, mais le second explique exactement ce que je disais (utilisation du pipeline, latence mémoire).
Dans le deuxième article, ils revendiquent un facteur 1.5-2 au mieux, pas un facteur 4.
J'avais dit 1.15-1.25, on peut atteindre 2 sur une workload favorable (ils parlent de transaction donc des trucs qui font pas d'accès mémoire et qui restent en repos sur des verrous).
Mais vraiment, le SMT/HT ne vaut pas du tout un cœur physique. On essaye de nous faire croire ça en parlant de "threads" processeur, mais c'est du marketing.
[^] # Re: Je vais choquer...
Posté par X345 . En réponse au journal sous-developpeurs-SSII. Évalué à 10.
Non mais sérieusement ! Tu essayes de justifier l'injustifiable.
Ben en fait on peut tout à fait annoncer directement que c'est 6 mois. Ça s'appelle un CDD. Tout simplement. Et je vois pas pourquoi un mec qui accepte un CDD (pour X raisons, ça peut aussi être plus pratique pour lui) serait moins motivé à faire son travail. Y'a tout à fait possibilité de proposer des compensations intéressantes (salaire, primes, conditions de travail etc.). Si quelqu'un travaille pour moi, il faut que je lui propose une compensation qui lui paraisse équitable. Oh mon dieu, quelle horreur ! Parce que le CDI, ça fait partie de la compensation, on accepte un salaire moindre en échange de stabilité etc. Dire qu'on va donner un truc et ne pas le faire après, c'est malhonnête. Et injustifiable.
Etre honnête c'est moins rentable ? Sans blague…
Pis bon, même légalement, tout ça est très très borderline. Parce que dans un CDD, la cotisation d'assurance est majorée. Mais forcément, c'est moins rentable de payer pleinement les cotisations, vaut mieux faire des CDD déguisés en CDI. C'est plus rentable.
Si c'est juste la rentabilité qui compte, j'ai quelques suggestions pour les salariés lésés :
Ok. Vraiment ok. Tu viens de comparer un humain à un serveur/une VM, ou c'est juste moi ?
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par X345 . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 3.
Complètement d'accord avec ça. En prenant tout en compte (mémoire, stockage, alimentation, réseau etc.), je suis pas du tout convaincu que de l'ARM soit plus efficace énergétiquement que du Intel.
[^] # Re: Manque l'essentiel
Posté par X345 . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 3.
Attention la performance des Atom basés sur l'architecture Silvermont est très supérieure à celle des Atom basés sur les architectures précédentes. En particulier, les Atom Silvermont (modèles commençant par C, e.g. C2750) ne sont pas des processeurs in-order, ce qui amène de très gros gains de performance.
Pour se donner une idée: Benchmark CPU - Atom N2800 vs Atom C2750
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par X345 . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 3.
Apparemment, c'est ce que online a fait. Quand j'avais testé (pendant la phase bêta), le stockage était accédé via un network block device. La latence était d'environ 1 ms et le débit de 50 Mo/s.
Je suis d'accord avec ta remarqué sur la pression réseau. D'ailleurs ceux qui se souviennent des RPS de chez OVH et deux leur stockage iSCSI le savent bien. À voir donc si la performance de la plateforme se dégrade avec beaucoup d'utilisateurs.
Autre hypothèse, je crois que les SoC Marvell Armada disposent de deux interfaces ethernet chacun, peut-être qu'ils on un lien réseau dédié stockage.
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par X345 . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 3.
Oui, d'ailleurs, c'est exactement ce que Online a fait : https://www.scaleway.com/features. Ils sont pas a des centaines, mais l'idée est la.
Par contre, la dernière fois que j'avais testé, le stockage était accédé via la réseau, chaque SoC n'a donc pas son stockage dédié.
[^] # Re: Power et little endian
Posté par X345 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
Éventuellement un gros cache L3/L4 ça peut aider dans certains cas particuliers (genre bases de données et join). Pour la fréquence plus élevée, ça aidera inconditionnellement, mais c'est pas forcément bon pour le ratio performance/watt. À fréquence équivalente, je sais pas si du POWER fait mieux que de l'Intel. J'imagine qu'il faut benchmarker en fonction des applications pour voir ce qui se comporte le mieux.
Le POWER8 a 12 cœurs, ce qui signifie qu'a un instant donné 12 threads s'exécutent en même temps. Le Xeon en a 18, ce qui signifie qu'a un instant donné 18 threads s'exécutent en même temps.
Faut pas tomber dans le panneau de cette dénomination de "threads" processeurs et imaginer que 96 threads s'exécutent en même temps. Le 8 threads/cœur veut juste dire que chaque cœur a 8 jeux de registres et donc qu'un cœur peut switcher entre 8 threads sans faire d'accès mémoire. Mais à un instant donné, on a 1 thread par cœur qui s'exécute. Le SMT (Simultaneous MultiThreading) ou l'HyperThreading (HT) permet juste de (1) assurer que le pipeline des processeurs est bien rempli et (2) éviter la latence mémoire au moment d'un context switch.
Par exemple, en pratique, sur du Intel, l'HT (2 threads/cœur) amène un gain de 25% de performance au mieux. C'est souvent 10-15% voire même 0 sur des applications déjà optimisées.
Merci pour le reste de ton commentaire (slicing hardware des cœurs CPU, compression mémoire, hyperviseur), je connaissais pas du tout ça. Effectivement, ça fait pas mal de fonctionnalités utiles pour bien consolider, qu'on trouve pas sur du Intel.
[^] # Re: Power et little endian
Posté par X345 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 4.
Je n'ai pas eu de serveurs POWER entre les mains à l'exception de VMs Runabove (POWER8), donc je ne remets pas ton expérience en cause.
Cependant, d'après Wikipedia, ils semblent que les POWER7 implémentent le jeu d'instructions PowerISA 2.06. Et d'après la documentation PowerISA 2.06, il semblerait que les POWER7 permettent d'adresser la mémoire en big/little endian, voir les sections Book I.1.9 "Storage Addressing" et Book II.1.6.5 "Endianness". Bon après, c'est juste des informations théoriques, je ne sais pas comment ça marche en pratique.
Oui, on est bien d'accord sur ta dernière remarque. D'ailleurs il y a du bon gros Vendredi dans les slides que tu as linké, merci :P :
Pour y'a quand même des points forts, notamment au niveau de la bande passante mémoire (65Go/s sur un Xeon et 200-400 Go/s sur un POWER8). Peut-être que le SMT à 8 threads/cœur apporte également un gain sur certaines workload.
Personnellement, je suis pas rassuré de voir le marché mondial des processeurs serveurs aux mains d'une seule boite, donc les alternatives m'intéressent. Mais faut quand même reconnaître que les générations actuelles de Xeon sont très performants…
Ça chauffe pas tant que ça un Xeon de nos jours donc grille pain ça semble exagéré quand même. Surtout en face de POWER cadencés à 4+ Ghz, ça doit être autre chose le refroidissement.
C'est quoi les fonctionnalités des POWER qui permettent de consolider mieux que sur du Intel (c'est une vrai question, j'en sais rien) ?
[^] # Re: DELL PowerEdge
Posté par X345 . En réponse au message Recommandations de modèles/marques serveur 1U pour installation Debian ?. Évalué à 2.
Je sais pas si on s'est bien compris, je ne suis pas contre le RAID hard inconditionnellement. Notamment, les caches présents sur certaines cartes peuvent apporter des gains de performances sur certaines workload.
Je disais juste de faire attention avec les cartes RAID bas de gamme, elles ont souvent de mauvaises performances (inférieures au RAID logiciel…) et causent plus de problèmes qu'elles n'en résolvent. En particulier, j'ai déjà eu des problèmes en RAID5 avec des H310.
Comme règle approximative, si c'est pour acheter une carte RAID sans cache, autant faire du RAID logiciel.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par X345 . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 1.
Des noms, des noms, des noms…
[^] # Re: DELL PowerEdge
Posté par X345 . En réponse au message Recommandations de modèles/marques serveur 1U pour installation Debian ?. Évalué à 4.
Oulà non, de manière générale, il faut fuir les cartes RAID bas de gamme comme la peste. En particulier, on a déjà eu de GROS problèmes de performance avec la H310 en particulier sur du RAID5, et on est pas le seuls apparemment :
Dell PERC H310 Controller RAID 5 Performance Issues
Donc les cartes c'est soit haut de gamme (avec cache flash + batterie), soit c'est RAID logiciel.
# Trolololo
Posté par X345 . En réponse au journal Ne dites plus GNU/linux, mais GNU/systemd. Évalué à 10.
lolololo…
Le github trololo : https://github.com/systemdaemon/systemd/tree/master/src/linux
Le vrai github de systemd : https://github.com/systemd/systemd
Et on est pas DU TOUT vendredi. Pas du tout.
[^] # Re: Restauration à 30Mo/s sur les deux machines ?
Posté par X345 . En réponse au message MySQL - Gros problème de performance. Évalué à 3.
Pour ioping, tu as les même résultats sur l'ancienne et la nouvelle machine, ~160Mo/s en lecture et ~75 IOPS dans les deux cas, ce qui correspond à des performances normales.
Je vais essayer de regarder tes résultats
iozone, c'est toujours difficile à interpréter. Mais effectivement, y'a de sacré différences entre tes deux machines, et la différence de performance de MYSQL vient sûrement de là. Probablement la carte RAID de l'ancienne machine aidait vraiment.Pour avoir des résultats plus faciles à interpreter dans un premier temps, tu peux faire des tests avec ioping en écriture (ioping -W) mais lis la page de man avant pour ne pas perdre de données.
Pour ce que est de la configuration, j'irais jeter un œil du côté de readhead, désactivation du NCQ etc. plutot que dans la configuration de MySQL.
Une autre hypothèse à vérifier si tu as des disques avec des secteurs 4k sur la nouvelle machine (Advanced Format 512e etc.) : est-ce que mdadm ne fait pas n'importe quoi au niveau de l'alignement du RAID ?
# Restauration à 30Mo/s sur les deux machines ?
Posté par X345 . En réponse au message MySQL - Gros problème de performance. Évalué à 2. Dernière modification le 27 mars 2015 à 13:58.
Avant de faire des corrections/réglages, j'aime bien avoir identifié de manière certaine la cause du problème de performance. T'as déjà fait des tests pertinents (hdparm, écriture RAM->disque), qui permettent déjà d'éliminer des causes probables de problèmes de performance.
Un truc me fait cependant tiquer. Sur les deux machines, l'écriture se fait à ~30 Mo/s pendant la restauration d'une sauvegarde. C'est étrange parce que si la restauration prend deux fois moins de temps sur une machine que sur l'autre, on s'attendrait à ce qu'une machine écrive 2 fois moins vite que l'autre (grosso modo).
Pour voir ce qu'il se passe exactement, tu peux mesurer la vitesse d'écriture disque pendant les 8h ou 14h de la restauration de la sauvegarde. Le plus simple est de bidouiller avec iotop : Measure I/O over time
S'il te reste du temps, je pense qu'il serait utile de tester la performance en termes d'IOPS des deux machines :
ioping
$ ioping -RL /dev/md4 # Débit en lecture
$ ioping -R /dev/md4 # IOPS en lecture
iozone
$ iozone -a # Tous test iozone (write, read, reread, rewrite)
[^] # Re: à l'ancienne ou presque
Posté par X345 . En réponse au message Logiciel de comptabilité simple. Évalué à 3.
Moui, mais je voudrais me souvenir de ce que j'ai fait avec les 40 euros. Je claque ~90€/mois en liquide mais j'ai aucune idée de ce que j'en fais. Et comme je fais mes comptes une fois tous les trois mois, je m'en souviens jamais. Clairement si je claque 90€/mois au bar, faut que je me calme. Si par contre c'est de la bouffe, je peux pas y faire grand chose.
Pas moi. C'est précisément ce qui m'intéresse, mais c'est trivial à faire sur un tableur une fois qu'on a les données. Une pivot table, deux trois average(), un graphique et ça roule.
Mon problème, c'est vraiment de pouvoir ventiler les données.
J'utilise un tableur pour l'instant, mais c'est chiant de tout classer à la main, fusionner à la main le fichier téléchargé depuis le site de ma banque etc. J'utiliserait bien une application de compta, mais c'est à peine plus pratique que le tableur.
[^] # Re: Certes
Posté par X345 . En réponse au journal L'autohébergement, c'est pas gagné. Évalué à 10.
Si j'étais un vendeur de voiture, et que je devais estimer le nombre d'acheteurs qui font de la conduite sportive sur circuit par rapport au nombre susceptible de faire des excès de vitesse sur les routes nationales, j'aurais limité tous mes modèles à 130 km/h.
Ça n'est vraiment pas acceptable qu'un FAI interdise (ou empêche grandement) l'envoi de mail à partir d'une connection internet. D'autant plus que là, il n'y a vraiment pas de vies en danger.
Si on veut combattre le Spam, y'a une solution toute simple : Le FAI désactive l'envoi de mails par défaut, et laisse une option à activer dans une interface d'administration pour le pourcent de geek qui veut héberger son mail.
Nan, parce jusqu'à preuve du contraire, on lui a vendu un accès internet, et on est pas censé lui dicter quoi faire avec.
[^] # Re: Logiciel libre / serveur distant
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 1.
S'indigner, c'est bien. Lire le journal, c'est mieux…
Je parle justement des problèmes de l'auto-hébergement sur un serveur personnel dans le journal. Et je sais pas ou tu as vu que je proposais de mettre mes données chez Google. Je pars justement du constat que beaucoup de gens le font et que ce n'est pas souhaitable.
[^] # Re: Au contraire
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 4.
Pour cette mode des applications smartphone, tu as raison, depuis quelques années la mode est à l'installation d'applis natives. Je pense que ça tient à la faisabilité technique (et pas au fait que les gens sont idiots…). Par exemple, c'est facile de faire une appli qui accède au micro, à la cam, au GPS, c'est plus difficile en web. Même chose, c'est facile de faire des applications qui répondent au gestures (swipe, pinch to zoom etc.), en web c'est plus compliqué. Même chose, je suppute que les bibliothèques graphiques sont plus faciles à utiliser pour faire des applications natives que les bibliothèques graphiques pour faire du Web (même si ça change, hello WebComponents). Peut-être aussi à la réactivité sur les téléphones les plus anciens. Une application en Java, c'est plus rapide qu'un truc en JS.
Pour Google Maps, par exemple, moi je suis content de pouvoir utiliser le GPS de mon téléphone. Également l'application native me permet de zoomer plus facilement.
[^] # Re: Perdu
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 4.
Une autre réponse que je voulais apporter à ta question, c'est que tu utilises une interface native pour accéder à un service Web, ça ne change pas grand chose. Tu est toujours en train d'utiliser un service Web.
Par exemple, quand tu utilises Dropbox (ou Google Drive), tu utilises peut-être l'application native Dropbox. Mais tu utilises aussi le côté serveur de Dropbox, sur lequel tu mets tes données d'ailleurs.
Mon problème est que je ne veux pas utiliser le service Dropbox, parce que je veux garder mes données et ne pas les filer à une entité tierce. Je veux un service qui fasse comme Dropbox (parce que la synchro et la collaboration, c'est pratique), mais que j'installe moi-même sur une machine que j'administre moi-même pour garder la maîtrise de mes données.
Tu me répondras que je peux utiliser Owncloud (et c'est vrai). Je trouve que ça reste un peu chiant à installer, il faut que j'installe le paquet, que je configure nginx et php-fpm, que je vérifie que ma config est bien sécurisée. Pour moi c'est pas trop un gros problème, mais je trouverais ça bien que tout le monde puisse installer owncloud facilement, et arrête qu'ils arrêtent d'utiliser Dropbox par la même occasion.
[^] # Re: Qui est "nous" ?
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 3.
Je globalement très d'accord avec ta remarque, et j'ajouterais que la majorité de la population utilise uniquement des applications simples : client mail, messagerie, traitement de texte etc.
Encore que pour les jeux vidéos, je ne suis pas sur. Nvidia bosse déjà sur des solutions dites de Gaming as a service. L'idée est que le rendu du jeu vidéo se fasse sur le serveur et soit streamé sous forme de vidéo. Pour l'instant, y'a encore des problèmes de latence.
Peut-être que ça marchera, peut-être que ça ne marchera jamais. Ça aurait quand même de bon côtés : pour les LAN parties, pas besoin de faire attention à installer la même version du jeu sur tout les postes. D'ailleurs pas d'install du tout, pas de téléchargement de mises à jour de 14Go avant de jouer. On clique et le jeu se lance. Au niveau facturation aussi, on peu imaginer un service d'abonnement où pour un abonnement mensuel donné, on a accès à toute une bibliothèque de jeux…
[^] # Re: Pas concerné
Posté par X345 . En réponse au journal Linux pas prêt pour le desktop ? Pas grave !. Évalué à 7.
Évidemment, si tu n'utilises pas du tout d'applications Web, tu peux te sentir "pas concerné" par tout ça. Tout comme les utilisateurs d'applications en ligne de commande sont pas tellement concernés par ce qui se passe dans le domaine des interfaces graphiques.
Mais quand même, tu auras remarqué qu'il y a un grand nombre de tes contacts qui utilisent des applications Web, que ce soit Facebook, Gmail ou Google Docs. Et ça pose des problèmes de maîtrise de ses données personnelles. En tant que "geek" (ou au moins personne qui comprend l'informatique), je me sens un peu obligé de "montrer la bonne voie" pour garder la maîtrise des ses données.
Et clairement, je ne peux pas opposer LibreOffice à Google Docs. La possibilité de travailler en temps réel à plusieurs est ce qui attire dans ces plateformes. Aussi le fait qu'ils n'ont pas besoin d'aller télécharger et installer un logiciel. Je voudrais pouvoir proposer WebODF par exemple, mais ce genre d'applications Web reste chiant à installer, même pour quelqu'un qui maîtrise un peu l'informatique.