Re: [OSM-talk-fr] Mise en place d'un miroir OSM
2013/2/9 Christian Quest cqu...@openstreetmap.fr: Ce système de proxy/cache c'est ce que nous avons mis en place sur 2 Je ne ferais pas la promotion de ce proxy/cache tant que le problème de la confidentialité des authentifications ne sera pas résolu. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
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
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
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
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
Le 10 février 2013 13:44, Christophe Merlet red...@redfoxcenter.org a écrit : 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 ? Usage purement local et certainement pas comparable en matière de matériel. Je n'ai tout bonnement pas besoin des mêmes performances, le nombre de requêtes à traiter est ridicule en comparaison. Au delà de ça, vous devez savoir comment optimiser le stockage sur vos serveurs, il n'y a de toute façon pas d'urgence de changer quelque chose au vu des ressources utilisées. Mais puisque vous avez donné ces stats pour répondre à la demande de quelqu'un pour lui suggérer de monter un serveur de tuiles, ces stats ne sont utiles que pour montrer les ressources réellement nécessaires. Bref ma réponse restait bien DANS le sujet. Si ce n'est pas le cas, alors même la réponse donnée avant moi au sujet de ces statistiques est également hors sujet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
En plus mon serveur local n'a pas de table d'inodes puisque son stockage est sous Windows. Le tuning est tout à fait différent, même si c'est du RAID (que j'ai monté en stripes de 64 Ko classiques). Je n'ai pas encore tenté d'augmenter la taille des tuiles stockées (cela demanderait une modif du serveur pour qu'il en retourne des fragments de 256x256 au lieu de la tuile stockée 512x512, et une autre modif du code générant ces tuiles stockées). Ce n'est pas ridicule : rien que pour gérer jusqu'au niveau 12 les tuiles du monde entier, on monte très vite en nombre de fichiers, et cela impose une charge importange sur le système de fichiers si on stocke tout dans le même dossier cache. Répartir les fichiers sur des dossiers multiples aide beaucoup l'OS à gérer les modifications et recherches rapides dans ce dossier (on sait que NTFS devient particulièrement lent à partir du moment où on met plus de 2000 fichiers dans un même dossier, mais on a aussi le même problème avec FAT pour les recherches où c'est le temps d'accès qui devient de plus en plus long, avec une charge supplémentaire sur la taille du cache en mémoire, sans compter aussi des problème de verrous exclusifs lors des modifs par des processus ou threads concurrents). Je n'ai aucune idée de la façon dont vous organisez le stockage sur votre serveur, en terme d'organisation des fichiers. D'une façon générale les système de cache de stockage cherchent à diviser les fichiers en de nombreuses sous-collections (thème déjà abordé concernant le cache JTiles intégré à JOSM qui souffre sévèrement de ce problème de manque d'organisation et qui impose une charge trop importante à l'OS hôte). Ces solutions se retrouvent dans tout bon navigateur Internet (même l'installation la plus simple d'IE crée un cache divisé en au moins 4 ou 5 sous-dossiers avec une distribution pseudo-aléatoire des contenus entre les sous-dossiers ; on a la même solution dans le cache de déploiement Java, et dans les caches des autres navigateurs comme Firefox, Chrome, Opera, ou dans les caches de proxy frontaux comme Squid... Ca demande un peu de tuning si on veut maintenir des collections importantes de fichiers). Le 11 février 2013 04:53, Philippe Verdy verd...@wanadoo.fr a écrit : Le 10 février 2013 13:44, Christophe Merlet red...@redfoxcenter.org a écrit : 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 ? Usage purement local et certainement pas comparable en matière de matériel. Je n'ai tout bonnement pas besoin des mêmes performances, le nombre de requêtes à traiter est ridicule en comparaison. Au delà de ça, vous devez savoir comment optimiser le stockage sur vos serveurs, il n'y a de toute façon pas d'urgence de changer quelque chose au vu des ressources utilisées. Mais puisque vous avez donné ces stats pour répondre à la demande de quelqu'un pour lui suggérer de monter un serveur de tuiles, ces stats ne sont utiles que pour montrer les ressources réellement nécessaires. Bref ma réponse restait bien DANS le sujet. Si ce n'est pas le cas, alors même la réponse donnée avant moi au sujet de ces statistiques est également hors sujet. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
Bonjour Claire ! Ce qui peut être utile ce sont deux choses: - un cache de tuiles (pour accélérer l'accès aux fond de carte OSM) - un proxy/cache pour l'API (pour accélérer l'accès aux données OSM) Il faut pour cela une machine sérieuse mais pas délirante, une bonne connexion à internet (permanente, IP fixe), et une alimentation électrique sans coupure. Le 9 février 2013 08:54, Claire Halleux claire.du@gmail.com a écrit : Bonjour, Il y a une institution ici en RDC qui serait susceptible d'accueillir OSM sur ses serveurs. Existe-t-il un document reprenant tous les critères techniques requis sur le sujet (et qui ne serait pas écrit en chinois... je ne suis pas une pro des serveurs et eux n'ont pas beaucoup de temps à consacrer à la prise de décision). Il s'agirait d'accueillir les données africaines au minimum, ou mondiales si cela pouvait correspondre à leurs moyens Sans doute ce thème a déjà été discuté dans le passé, si oui, pourrait-on me transmettre le lien de l'archive concernée. Merci et bon week-end, -- Claire Halleux - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Geographic Information Systems Specialist Kinshasa, Democratic Rep. of the Congo Mobile: +243 99 256 9980 http://www.rgc.cd ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
Bonjour Christian, Merci pour les infos, j'ai même trouvé les spécifications techniques précises pour le cache de tuiles: http://wiki.openstreetmap.org/wiki/Servers/Tile_CDN Aurais-tu des infos plus précises concernant le hosting d'un proxy/cache pour l'API? Merci Claire Le 9 février 2013 09:05, Christian Quest cqu...@openstreetmap.fr a écrit : Bonjour Claire ! Ce qui peut être utile ce sont deux choses: - un cache de tuiles (pour accélérer l'accès aux fond de carte OSM) - un proxy/cache pour l'API (pour accélérer l'accès aux données OSM) Il faut pour cela une machine sérieuse mais pas délirante, une bonne connexion à internet (permanente, IP fixe), et une alimentation électrique sans coupure. Le 9 février 2013 08:54, Claire Halleux claire.du@gmail.com a écrit : Bonjour, Il y a une institution ici en RDC qui serait susceptible d'accueillir OSM sur ses serveurs. Existe-t-il un document reprenant tous les critères techniques requis sur le sujet (et qui ne serait pas écrit en chinois... je ne suis pas une pro des serveurs et eux n'ont pas beaucoup de temps à consacrer à la prise de décision). Il s'agirait d'accueillir les données africaines au minimum, ou mondiales si cela pouvait correspondre à leurs moyens Sans doute ce thème a déjà été discuté dans le passé, si oui, pourrait-on me transmettre le lien de l'archive concernée. Merci et bon week-end, -- Claire Halleux - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Geographic Information Systems Specialist Kinshasa, Democratic Rep. of the Congo Mobile: +243 99 256 9980 http://www.rgc.cd ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Claire Halleux *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* *Geographic Information Systems Specialist * *Kinshasa, Democratic Rep. of the Congo* *Mobile: +243 99 256 9980* *http://www.rgc.cd* ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mise en place d'un miroir OSM
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 Donc pas besoin d'un monstre pour faire tourner ce service qui sera bien utile pour l'édition et la réutilisation de données. Le principe est expliqué ici: http://wiki.openstreetmap.org/wiki/FR:Servers/api.openstreetmap.fr Le 9 février 2013 18:11, Claire Halleux claire.du@gmail.com a écrit : Bonjour Christian, Merci pour les infos, j'ai même trouvé les spécifications techniques précises pour le cache de tuiles: http://wiki.openstreetmap.org/wiki/Servers/Tile_CDN Aurais-tu des infos plus précises concernant le hosting d'un proxy/cache pour l'API? Merci Claire Le 9 février 2013 09:05, Christian Quest cqu...@openstreetmap.fr a écrit : Bonjour Claire ! Ce qui peut être utile ce sont deux choses: - un cache de tuiles (pour accélérer l'accès aux fond de carte OSM) - un proxy/cache pour l'API (pour accélérer l'accès aux données OSM) Il faut pour cela une machine sérieuse mais pas délirante, une bonne connexion à internet (permanente, IP fixe), et une alimentation électrique sans coupure. Le 9 février 2013 08:54, Claire Halleux claire.du@gmail.com a écrit : Bonjour, Il y a une institution ici en RDC qui serait susceptible d'accueillir OSM sur ses serveurs. Existe-t-il un document reprenant tous les critères techniques requis sur le sujet (et qui ne serait pas écrit en chinois... je ne suis pas une pro des serveurs et eux n'ont pas beaucoup de temps à consacrer à la prise de décision). Il s'agirait d'accueillir les données africaines au minimum, ou mondiales si cela pouvait correspondre à leurs moyens Sans doute ce thème a déjà été discuté dans le passé, si oui, pourrait-on me transmettre le lien de l'archive concernée. Merci et bon week-end, -- Claire Halleux - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Geographic Information Systems Specialist Kinshasa, Democratic Rep. of the Congo Mobile: +243 99 256 9980 http://www.rgc.cd ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Claire Halleux - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Geographic Information Systems Specialist Kinshasa, Democratic Rep. of the Congo Mobile: +243 99 256 9980 http://www.rgc.cd ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
