Architecture et conception logicielle
Hello,
I have not found any real code to prepared statement in C for PostgreSQL.
Then I have do it:
prepared_statement.c on CatchChallenger code
Prepare, mean: fix, optimise and cache the execution plan, this prevent any change to execution plan and improve the security too
Cheers,
PS: inspired by http://zetcode.com/db/postgresqlc/
Bonjour,
Avec l’arrivé de HSA, de CPU avec beaucoup de coeur, l’exploitation de GPU via des binaires, … et pour ne pas avoir de point de congestion, il deviens intéressant de mettre non pas toutes les vm sur tout les CPU, mais les vm sur un groupe de CPU définit, cela améliore la localité des données réduit la bande passante inter-coeur (seul les CPU proche communique), réduit les changements de contexte (moins de bande passante mémoire et une meilleure mise en cache dans le L1/L2 du cpu) et limites les ressources de la vm sans surcharge d’un ordonnanceur devant gérer les taches en compétitions.
Les GPU ont facilement 4000 coeur, mips I-Class I6500 aura 384 coeur, donc nous allons vers des hébergements moins puissant en mono-coeur, mais plus puissant en multi-coeur, ce qui ne vas pas sans crée des problèmes quand les personnes demandes pourquoi leur site (mal optimisé) est plus lent (sur une page).
Je suis encore sur le développements des concepts:
http://catchchallenger.first-world.info/wiki/Virtual_machine_on_GPU
Par exemple un noyau maitre (GNU/Linux) et des noyaux esclaves gérant leur zone (hdd via 3gp ou NFS, …).
Voir cela comme un réseau locale de serveurs, répartir la charge de tout les sites sur tout les serveurs pour essayer d’exploiter tout les cpu n’as pas de sens, il faut envoyer toutes les données sur tout les serveurs, les traiter, les fusionner, … changement de site, tout recharger, saturation du réseau, …
C’est mieux de mettre un groupe de site par serveurs.
C’est la même chose en local dans un GPU, un serveur multi socket. Sans parler des études démontrant que la bande passante mémoire par cpu diminue pour avoir plus de cpu.
En programmation en multi-CPU, on utilise en générale des verrous/entier atomiques, ce qui deviens rapidement pénalisant et empêche l’exploitation du multi-coeur.
Si par contre la base de donnée est sur un coeur et l’application (page web php?), ce sont des queues nativement qui sont utilisé (Socket TCP, Socket Unix) ce qui permet d’éviter les blocages pour attente de la mémoire principal. Les taches (traitement sur les données) sont vraiment indépendante, et une tache pas codé (php lent) ne ralenti pas le hardware.
L’exploitation du multicoeur au niveau de l’hébergement n’est pas la même que au niveau du logiciel. Elle demande un minimum de bon sens. Certain diront: je veux tout les CPU sur toutes les machines virtuelle, même si le prix est peu de performance… d’autre: je veux pas optimiser mon site web, le hardware doit me donner plus de puissance, …
L’exploitation commercial de ces concept ce traduit en bolivie avec l’ouverture de mon datacenter avec 50 serveur pour commencer avec une architectures traditionnelle, mais surement l’exploitation de mips I-Class I6500, GPU ou Cavium ThunderX. Le tout en linux et 100% libre, sans routeur administrable mais avec tout les functions de ces derniers via la virtualisation vm et réseau et du PaaS (VPS). Au programme IPv6, tunneling + compression, pearing et industrialisation maximum comme ovh.
Bonjour,
La version 1.0 de Zstandard (ou zstd) est sortie. Elle se définie elle-même avec:
Zstandard est un algorithm de compression temps réel, fournissant de haut ratio de compression. Il offre une large gamme de compromis compression/vitesse, tout en étant soutenu par un décodeur très rapide (voir benchmarks). Il offre aussi un mode spécial pour les petites données, appellé compression par dictionaire, et peu crée un dictionaire depuis n’importe quel échantillon. La bibliotéque Zstandard est fourni comme logiciel libre sous la license BSD.
Le ratio de compression est proche de zlib qui est la référence en terme de compression. Elle est développer depuis longtemps par l’entreprise Facebook. Mais elle as des vitesses de compression et décompression bien meilleur que zlib. Ce qui pour moi la place comme bonne concurrente pour être le standard de compression des 30 prochaines années. De meilleur standard de compression veut dire une meilleur qualité de navigation et moins de ressources serveurs, et donc moins de coût pour Facebook et tout autre entreprise utilisant ces standards.
Son ouverture et interopérabilité avec une liste impressionnante de language vont participer fortement à son utilisation. Son utilisation pour le streaming est bonne car la compression est très efficace sur les petit contenu de données.
Je ne prévois pas changer CatchChallenger dans un futur proche, car bien que super, ce standard obligerai a refaire le packaging, le protocole, et la compression est peu utilisé dans le coeur du protocole de CatchChallenger (données vraiment trop petite ou non compressible).
Faite vous votre avis.
Pourquoi je l’utilise? Car c’est un format libre, ce qui garantit l’interopérabilité. Cela est important car cela me permet d’avoir toujours un logiciel pour faire et lire l’archive, sans license ou redevance. Cela permet d’encoder un tar sous Windows, Linux, Mac. Le faire ma propre lib pour le lire (donc réduire la taille du code car je limite les fonctionnalités à ce que j’ai besoin).
Cela me permet de découplé le format de stockage et la compression en elle même. Utiliser le format Tar avec gzip, zlib ou autre.
Vous avez les données, le contenu des fichiers. Et les métadonnées, nom, chemin, chmod, utilisateur, groupe, date de creation… Le format Tar tar fonctionne par bloque, les trous entre les bloques sont remplit par des 0 binaires. Le format est orienté stockage sur bande, il date de 1979 (normalisation 1988) mais eu des revisions entre temps.
Le fait de ne pas faire une bête sérialisation peu être gênant pour les systèmes de compression car il y as un trou de X 0 binaire. Cela rajoute du bruit, ce qui est problématique pour optimiser la compression. Si en plus l’on rajoute le faite que les entier sont stocké en chaine, ce qui réduit encore le ratio de compression comparé au binaire (voir: Compression et Binary dans le wiki de CatchChallenger). Cela réduit aussi les performances de l’encodeur et décodeur Tar de travailler en chaine et non pas en binaire (sans parler des limitations de la longueur des nombres représentés).
Un format mieux étudié pourrai avoir une taille bien inférieur sans compression et un meilleur ratio de compression.
Supprimer des meta données serai une bonne idée. Par exemple dans mon décompresseur je ne prends en compte QUE le fichier et son nom et j’ignore une grande partie et méta données: chmod, utilisateur, groupe, date de creation…
Je vais continuer à utiliser Tar dans le cadre de mes logiciels pour faciliter la création de plugin pour Ultracopier/Supercopier et pour l’intégration facile coté serveur dédié (99% de unix) pour CatchChallenger via un mirroir http (car pour le self hosting il y as déjà un rsync simplifié qui rends toute utilisation de Tar inutile).
Faire mon propre format n’est pas un probléme, le probléme serai de faire/maintenir et distribuer l’encodeur et le décodeur pour ce format.
Bonjour,
Pour les besoins de CatchChallenger, j’ai exploré des base de données NoSQL.
C’été mon 1er choix. La mise à l’échelle (scalabilité) est bonne. Il prends en compte le datacenter.
Mais le pannel de controle fort sympatique qu’est OpsCenter est réservé a RedHat et debian, pourquoi il ne peu pas juste demander les dépendances qu’il as besoin, voir les embarqués si elle ne sont pas trés commune?
J’ai été obligé de rajouter des clef primaire la ou ce n’est pas utile. Les index uniques sur du multi colonne ne sont pas natif et vu que j’ai rien compris sur comment faire ce CUSTOM INDEX et que cela affecte les performances, j’ai dit adieux.
Sur gentoo, je suis bloqué en 2.6 à cause d’un conflit de dépendances avec kleopatra (KDE). Même si c’est plus de la faute de kleopatra, c’est génant.
J’ai donc tenter sur un de mes ARM, et là on me dit que sur ARM, et particulièrement ARM 32Bits cela ne sera jamais supporté. Donc poubelle.
Bien, compatible car j’utilise des functions simples (ce qui me rends compatible avec 100% des SQL), je note cependant que certaines fonctionnalités ne sont pas dispo sur toute les architectures: TokuDB pas dispo sur ARM…
Nous somme en 2016 les gas! Mềme Mingw supporte gcc 4.9, ce qui donne accès a une abstraction à la fois de l’architecture et de la plateforme.
Pour être indépendant de la plateforme il y as plein de libs connu, sans compter la compatibilité entre les unix, et grace à mingw avec windows.
Coté architecture, il faut toujours avoir un failback en C/C++ pour les architectures moins optimisé mais pour avoir un support et du code lisible et vérifiable. Le double support 32Bits et 64Bits est super facile à faire si ont respecte la norme. Hors mit ca je vois pas la moindre raison que votre code C/C++ ne marcherai pas sur une autre architecture.
Le 32Bits ne vas jamais disparaître car c’est le moyen le plus effectif pour avoir des système embarqué avec peu de consommation. En plus cela permet de réduire lors d’utilisation forte de pointeur l’empreinte mémoire (jusqu’as 2x de réduction, BTree, hash table, …). Si vous utilisez moins de 4Go de mémoire, le 32Bits est fait pour vous. C’est pour cela qu’existe aussi x32, cela permet sur x86_64 de tiré partie du mode 64Bits mais en ayant un mode d’adressage en 32Bits (donc max 4Go) mais avec la réduction de l’empreinte mémoire du 32Bits. Cela ne me surprendrai pas de savoir que les GPU ont des cpu en 32Bits.
Bye.
Bonjour,
Je suis tomber sur cet article:
http://thebacklog.net/2011/04/04/a-nice-picture-of-dependency-hell/
Voila la visualisation des dépendances des logiciels et libs:
Il y as des dépendances dans tout les sens, mais le pire c’est les dépendances circulaires, il vous faut A pour avoir B, mais B pour avoir A… et donc comment vous faite depuis 0? Vous mettez un A compilé trouvé sur internet, vous compilez B, puis compilez A et écrasez le A de internet.
En 5 ans le nombres de packets à augmenté, les dépendances se sont complexifié. Cela rends la maintenance d’un OS plus compliqué. Faire l’arbre de dépendances pour calculer les dépendances à installer avant le packet deviens de plus en plus complexe.
Un logiciel peu vouloir une lib en version 1.2 et pas moins ni plus, et un autre utilise cette libs en version 1.3 minimum.
A votre niveau, que pouvez vous faire? Voila une serie de conseille qui sont à appliquer avec intelligence, et non comme des régles strictes:
Si vous faite une lib, voila les conseilles:
Voila, en espérant vous avoir éclairé.
Bonjour,
Je rentre dans une phase de testing, benchmarking et stabilisation dans CatchChallenger. Je n’est pas encore fait l’optimisation, juste respecter les régles de codage.
Les temps noyau, et gestion de matériel dans le cas du raspberry pi sont bien supérieur aux temps en espace utilisateur. Donc un load balancer prendrais autant de charge CPU que l’application en elle même. Le seul cas réel d’un load balancer serai un gros load balancer et de toute petite nodes. Mais dans tout les cas le load balancer ne pourra jamais gérer plus de client que les nodes elle même.
Pour la haute disponibilité: Il suffit de faire soit un/des haproxy en mode tcp, ou faire cela via DNS (ce qui permet de faire des personnalisation par pays pour optimiser le trafic, et cela est parfaitement scalable)
Répartition de charge: impossible via un logiciel si les serveurs sont symétrique, car il passerai plus de temps cpu a répartir la charge que à travailler (induirai des latences et sous chargerai les serveurs). Pour les serveurs logins, la gestion par pays des DNS permet cela.
Et pour les games serveurs? Pour la haute disponibilité: Pas besoin, le serveur est down, les joueurs peuvent aller jouer sur un autre serveur similaire. Répartition de charge: Les limites par serveur force les joueurs a se répartir sur les différents serveurs, sans compter avec le faire qu’il vont sur les serveurs les plus proches de chez eux.
Un raspberry pi 1, ARMv6 à 700Mhz tiens une charge de 60000 joueurs. Ceux sans optimisation. Pour que une attaque DDOS soit intéressante il faut que le prix de l’attaque soit bien inférieur au prix du préjudice. Comme ici le botnet pour attaquer CatchChallenger doit être vraiment três grands face aux peu de serveur pour surporter un tel charge, la possibilité d’une attaque DDOS est relativement faible.
Attention: Les options du serveurs ont une forte influence sur la monté en charge et le confort des utilisateurs.
Les maps infini sont théoriquement supporté (infini à la minecraft: trop grande humainement pour être explorer). La gestion et mise a l’échelle as été fortement amélioré. Il deviens donc envisageable de faire les maps par génération procédurale.
Raspberry pi 3
Je ne vous conseille pas le raspberry pi 3 car pour le même prix vous avez the le Odroid C2 qui vous offres: une bien meilleure carte graphique, une mémoire bien plus rapide, plus grande, un meilleur bus de communication entre les composants, une carte réseau meilleure et mieux interfacé (pas via l’usb), l’eMMC, …
N’hésité pas a acheter les logiciels qui vous ont plus ou apporté quelque chose (CatchChallenger).
Bye,
Bonjour,
Sur une section de code sensible je me suis demander, ce qui est mieux (teste fait en C++):
int a;
while(10000000x)
a=10;
Ou:
int a;
while(10000000x)
if(a!=10)
a=10;
Avec la 1ère partie, une vague d’information qui viens du coeur du cpu viens remplir les différents buffer (L1, L2, L3) jusqu’as la mémoire centrale de manière non bloquante. Ce qui provoque une grosse consommation sur tout le chemin de l’information. Cela est plus performant sur ARMv6 in-order surchargé car cela est non bloquant (2x), mais plus lent de 30% sur un x86 vide.
La 2ème partie est plus lente sur un système surchargé car le CPU passe sont temps a remettre en cache l’information à cause des changements de contexte qui purge les différents cache. Bien sur cette solution est préférable si cela permet d’évité un traitement lourd, mais la première solution est mieux pour la gestion simple de flags.
Bye,
Bonjour,
Pour moi les CPU haute densité type Cavium ThunderX CN8890 ARMv8 sont l’avenir dans le monde des serveurs, AMD a beau sortir ces Opteron A1100, ont est loin des 4$ par cpu de pine64 ou 8$ par cpu des raspberry pi.
Point que je prends en compte:
A standard Linux system that struggles at forwarding 500,000 packets-per-second
, si les meilleurs x86 ont du mal, les ARM qui ont moins de instruction par secondes aux MHz…
Donc pour moi la carte H270-T70 de gigabyte est une bonne direction.
Bye,
Bonjour,
Une langage informatique c’est une représentation d’une logique, celle si peu être orienté facilité (python, php) ou passé un maximum de détails au compilateur et étant proche du hardware (C, C++, ce qui permet de bien meilleur performance). Mais dans tout les cas il peu être compilé, interprété, JIT.
JIT pour wikipedia: Dans le domaine de la programmation informatique, la compilation à la volée, aussi connue sous le nom de traduction dynamique (just-in-time compilation ou JIT compilation en anglais), est une technique visant à améliorer la performance de systèmesbytecode-compilés par la traduction de bytecode en code machine natif au moment de l’exécution. La compilation à la volée se base sur deux anciennes idées : la compilation de bytecode et la compilation dynamique.
Que change le JIT?
var toto=fichier de config[Toto]
if(toto==X)
faire une chose
else
faire autre chose
La condition vas toujours être vérifié, pas en JIT. Car le JIT vas détecter que après la première ligne la variable ne vas jamais changer, et donc vas faire cela:
if(true)//la condition est toujours vraie/fausse car toto ne change jamais après avoir été changer du fichier de config
faire une chose
else
faire autre chose
Et vas donc finir par ne garder que la branche qui est toujours exécuté:
faire une chose
Wikipedia: La prédiction de branchement est une fonctionnalité d’un processeur qui lui permet de prédire le résultat d’un branchement. Cette technique permet à un processeur de rendre l’utilisation de son pipeline plus efficace. Avec cette technique, le processeur va faire de l’exécution spéculative : il va parier sur le résultat d’un branchement, et va poursuivre l’exécution du programme avec le résultat du pari. Si le pari échoue, les instructions chargées par erreur dans le pipeline sont annulées.
Cela permet donc du diminuer ce besoin hardware, augmenter fortement les performances lors des hardwares n’ayant pas une prédiction de branchement performante. Dans tout les cas il est mieux de sortir les conditions de vos boucles et mettre des boucles différentes dans plusieurs branche, cela fait en effet similaire (mais cela peu varié en fonction du cas).
En espérant vous avoir éclairé avec cette article en français.
