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
