A part le fait que tu es complètement hors sujet dans ce fil de discussion, je suppose que tu t'es monté ton propre serveur de tuiles pour tester. Tu peux nous dire les perfs que tu obtiens pour comparer ?
Le dimanche 10 février 2013 à 12:49 +0100, Philippe Verdy a écrit : > Une remarque au sujet de ces stats : l'utilisation des inodes à 30% > dépasse largement l'utilisation du volume en terme d'espace (voisin de > 8%), cela suggère que les tuiles stockées sont 4 fois trop petites et > que le serveur de tuiles devrait soir retourner des tuiles 4 fois plus > grandes en surface, soit stocker des tuiles 4 fois plus grandes en > surface, quitte à faire un split à la volée (et vu l'usage de la CPU > ce complément de travail ne devrait pas lui demander beaucoup > d'effort, surtout si le redécoupage à la demande utilise aussi un > autre cache disque qui n'a pas besoin d'être très gros non plus). > > Bref au lieu de stocker des tuiles 256x256, stocker des tuiles 512x512 > serait plus optimal, même si le serveur continue de retourner aux > clients des tuiles 256x256 (quarts d'image). > > Si cela ne marche pas (limite de CPU atteinte), un tuning du système > de fichiers pour étendre le taux entre la taille de la table des > inodes et la taille du volume pourrait être utile, afin de déterminer > la bonne taille minimale du système de fichiers à utiliser pour le > cache de tuiles. > > (Dans l'état actuel, ce cache de tuiles précalculées me semble très > largement surdimensionné en taille totale de volume, et le serveur > semble donc taillé déjà pour accueillir de nouvelles couches de rendu > alternatif ; réduire ce système de fichiers à ce qui est suffisant > permettrait même des optimisations en terme d'I/O, avec une taille > plus réduite de la table d'inodes et de la bitmap d'allocation. > D'autres optimisations sont encore possibles : utilisez-vous une > config RAID5 pour la sécurité du cache ? Cela ne semble pas utile, > aucune de ces données n'est critique, il me semble que la vraie limite > sur les iops ne peut être résolue qu'en multipliant le nombre de > disques dans la grappe et en utilisant des stripes assez petits pour > bien équilibrer les charges entre les disques; des stripes de 4 ou 8Ko > seraient suffisants pour les tuiles, plutôt que les classiques stripes > de 64Ko, sachant que les tuiles PNG 256x256 ont une taille voisine de > 16Ko ; cependant en quadruplant leur surface elles monteraient autour > de 64Ko et les stripes monteraient à 16Ko aussi de façon quasi > optimale). Reste alors à multiplier les disques en parallèle (pas > nécessairement en RAID, on peut aussi les distribuer par un hachage > sur une collection de petits systèmes de fichiers chacun sur des > disques différents ; le reste des disques pourra servir à faire des > volumes RAID pour les données critiques à préserver, mais pas pour les > caches de tuiles sur disque, surtout qu'il y a de la marge en plus > dans le cache en mémoire avant d'accéder à ces disques ; des baies > RAID à 16 disques ne sont pas difficiles à trouver et monter, sur > chacun on met un petit bout du cache de tuiles, et un processeur dédié > pour les calculer en local, le reste est partagé; et on peut alors > utiliser tout le reste des disques pour des tonnes d'autres volumes > précieux sur divers agencements RAID entre les disques, par exemple > pour la base de données qui prend un temps fou à charger, ou pour les > services d'exports de données, les backups systèmes ou pour > expérimenter des VMs supplémentaires) > > Le 9 février 2013 18:54, Christian Quest <cqu...@openstreetmap.fr> a écrit : > > Ce système de proxy/cache c'est ce que nous avons mis en place sur 2 > > de nos serveurs OSM-FR, la version "monde" tourne dans une VM et > > n'utilise que 512Mo de RAM (le reste sera utilisé par le cache > > disque), et 140Go de disque pour la DB. > > Voici ses stats: > > http://munin.openstreetmap.fr/osm11.free.org/osm103.openstreetmap.fr/index.html > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
