search

osm-fr / infrastructure

Handle tickets against osm-fr infrastructure
MIT License
22 stars 4 forks source link

performance tile.openstreetmap.fr #27

Closed Marc-marc-marc closed 5 years ago

Marc-marc-marc commented 6 years ago

Je m'étonne de la grande différence entre le serveur de rendu osm-fr et ceux osm.org le critère le plus frappant est le nombre de metatuile/second org ~11 fr ~1 https://munin.openstreetmap.org/openstreetmap/scorch.openstreetmap/renderd_processed.html https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/renderd_processed.html

la db a aussi régulièrement des pics de 2h de lag https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/index.html#osm

pistes :

yohanboniface commented 6 years ago

il y a nginx visiblement inutilisé qui tourne et qui pourrait être arrêté.

À ma connaissance il est utilisé en serveur de cache.

A voir si cela serrait pertinent ou pas de faire un rebase de l'upstream tout en y appliquant les spécifs osm-fr

À ma connaissance (bis), osm-fr n'est plus sur osm13. C'est seulement HOT, 2U, route500xxx.

Pour HOT, j'en suis à me demander si je vais pas faire un reboot en utilisant imposm à la place d'osm2pgsql pour avoir une base plus light et plus optimisée. Mais ça veut dire un serveur dédié, etc. Donc pas simple.

Marc-marc-marc commented 6 years ago

@jocelynj @cquest @yohanboniface je peux avoir access sudo sur osm13 (rendu hot) et osm25 (rendu osm-fr) pour ajouter les moniteurs manquant et analyser + en détail le reste ?

cquest commented 6 years ago

ça me va...

Avant de modifier quelque chose, préviens car c'est une stack un peu complexe. Les perfs ont complètement changé lors des mises à jour et j'ai jamais trouvé comment retrouver les perfs initiales :(

Marc-marc-marc commented 6 years ago

Merci.

ybon tu as raison, ngnix est bien utilisé mais le cache a l'air d'être systématiquement inutile http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/openstreetmap.fr/osm13.openstreetmap.fr/nginx_cache_ratio-day.png (l'absence de valeur jusqu'à hier est du à une erreur de config que j'ai corrigé qui fait que les requêtes de munin pour /nginx_status étaient erronément envoyée à apache) EDIT : les requêtes pour les tuiles vont normalement de tile.openstreetmap.fr @ osm23-rezopole directement vers apache @ osm13 les requêtes qui passent pas ngnix @ osm13 sont du soit à une erreur de config côté client (j'ai vu un downloader depuis QGIS) soit concerne qlq fichiers statiques html (qu'on pourrait faire passer par rezopole) et export (qu'on pourrait migrer sur le serveur download)

a noter un taux particulière faible de 7/sec fork rate et un taux d'interupt LOC élevé (peux être causé par 16 rendu // alors qu'il y a que 12 cœurs physiques). EDIT : Par comparaison avec scorch @ osm.org, cela n'a pas l'air d'être anormal.

premières propositions pour osm13 :

cquest commented 6 years ago

Je complète...

le nginx sur osm13 servait de cache avant qu'on ait celui de lyon. le cache de lyon tape directement sur apache nginx sert encore en front pour le contenu restant, des fichiers à télécharger, un peu d'HTML pour tile.openstreetmap.fr

Munin: ça doit être très marginal... mais oui, pas de problème

maxInterval: il ne sert que lors des rattrapages de retard. Dans ces cas, il est préférable de les faire par gros blocs, ça évite d'invalider les tuiles à plusieurs reprises (et potentiellement de regénérer encore plus de rendu en dirty)

les threads de renderd: on voit déjà sur les graphes que ça réduit le nombre de metatile générées par seconde, qui est le mesure ultime de performance...

Le CPU est largement sous utilisé (on est à 50%), les IO ne sont pas saturés (moins de 10%), on a de la RAM libre (forte utilisation par le cache kernel et postgres)... d'où mon incompréhension de ce qui coince.

Le graphe le plus marquant pour moi est celui-ci: http://munin.openstreetmap.fr/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph&plugin_name=openstreetmap.fr/osm13.openstreetmap.fr/renderd_queue&size_x=800&size_y=400&start_epoch=1492506371&stop_epoch=1527066371

La queue de renderd était quasiment vide avant novembre. Elle a commencé à se remplir régulièrement à partir du gros upgrade général.

Sur le débit de tuiles générées, la différence c'est pas énorme mais significative:

Environ 1.8 tuiles/s avant novembre

http://munin.openstreetmap.fr/static/dynazoom.html?plugin_name=openstreetmap.fr%2Fosm13.openstreetmap.fr%2Frenderd_processed&start_iso8601=2017-04-26T09%3A54%3A11%2B0200&stop_iso8601=2017-06-27T09%3A36%3A11%2B0200&start_epoch=1493193251&stop_epoch=1498548971&lower_limit=&upper_limit=&size_x=800&size_y=400&cgiurl_graph=%2Fmunin-cgi%2Fmunin-cgi-graph

Environ 1.2 tuile / s depuis janvier http://munin.openstreetmap.fr/static/dynazoom.html?plugin_name=openstreetmap.fr%2Fosm13.openstreetmap.fr%2Frenderd_processed&start_iso8601=2017-12-05T22%3A06%3A11%2B0100&stop_iso8601=2018-05-23T11%3A06%3A11%2B0200&start_epoch=1512507971&stop_epoch=1527066371&lower_limit=&upper_limit=&size_x=800&size_y=400&cgiurl_graph=%2Fmunin-cgi%2Fmunin-cgi-graph

On a perdu 1/3 de débit, ce qui peut expliquer que la queue de renderd se remplisse bien plus et sature 80% du temps.

Pour comprendre ce qui se passe, on peut partir des effets finaux (la queue qui se remplit) ou des mesures basiques CPU/IO/RAM.

Autre chose à regarder peut être... les requêtes qui arrivent... n'a-t-on pas des aspirateurs qui provoquent une surcharge côté rendu ? J'ai un peu regardé, mis des contremesures de base. Je vais recreuser un peu aussi de ce côté (j'ai en principe l'historique complet des logs)... mais ça n'explique pas la perte le 1/3 du débit de génération de tuiles.

Marc-marc-marc commented 6 years ago

munin-master coupé sur osm13

lag : je ne parlais pas du lag après une coupure de service où là effectivement il vaut mieux éviter d'invalider plusieurs fois des tuiles (suffit de changer le paramètre après une grosse coupure ou couper renderd le temps de récupérer le retard). Je parlais du fait qu'en permanence osm13 subissait jusqu'à hier tous les jours des pic de 4h de lag. http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/openstreetmap.fr/osm13.openstreetmap.fr/osm_replication_lag_osm2pgsql-day.png le lag a disparu après la modif d'hier. J'ai refais un test ce soir en saturer le serveur (exécution d'un render_list supplémentaire sur 12 threads), le lag de synchronisation est immédiat. Je propose de reporter la question maxInterval à + tard et de s'attaquer d'abord à la cause.

cache nginx sur osm13 : ne serrait-ce pas l'occasion de supprimer ce reliquat du passé ?

attention à l'interprétation de la charge CPU : avec 12 cœurs CPU / 24 HT, une utilisation actuelle > ~1200% sature le cpu. l'HT peux apporter un gain de ~10% mais pas doubler la charge utile cpu.

Pour les tuiles, même 1.8 metatuiles/sec de novembre est pour moi bien faible comparé à 10 metatuiles/sec de scorch @ osm.org https://munin.openstreetmap.org/openstreetmap/scorch.openstreetmap/index.html http://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/index.html ce qui frappe dans ce comparatif (si on ignore la différence du nombre de thread apache)

il manque peut-être des index sur la bdd

aspirateur de tuile : on en a vu un hier, mais vu que cela m'impacte pas le débit de rendu des tuiles, je remettrait cela à + tard. sauf qu'il faudrait éviter de servir l'aspirateur depuis osm13 (cfr point 3 ci dessus)

la majorité des plugins postgress ne fonctionnent pas sur osm13. ils n'arrivent pas à trouver la version de postgress. j'ai réussis à en corriger 2 en supprimant le check de version ou le code pour les versions 8.x mais les autres ne vont pas.

cquest commented 6 years ago

Ce lag s'explique tout simplement: le script d'update se désactive si le load de la machine est élevé, car il provoque pas mal d'I/O et va aussi amplifier le besoin de recalculer des tuiles. En réduisant le nombre de thread de rendu, on passe en dessous de la limite et l'update se fait toutes les 5mn comme prévu.

Le cache nginx... tu pense vraiment qu'il a un impact sur les perf globales du serveur ? Il était déjà là avant novembre...

La charge CPU: je ne m'explique pas pourquoi elle est si élevée, c'est surtout ça qui m'étonne le plus. Pour l'HT, oui, ça ne double pas magiquement la puissance brute, mais le graphe munin peut largement dépasser les 1200 et toucher les 24 qui indiquent qu'on n'a plus de marge sur le CPU. Je le constate lors de mes géocodages brutaux mensuels... mes 12 coeurs (24 HT). Je le constatais aussi lors de gros calculs de tuiles sur osm13 suite à des changements de feuille de style.

1.8 ou 1.2 metatuile c'est en effet bien inférieur aux serveurs de tuiles OSMF...

Un manque d'index sur la BDD, en principe pas, j'ai épluché les logs postgres sur les requêtes lentes pour y remédier... mais c'est à revérifier car vu que la base a été ré-importée de 0 suite à la panne du SSD en novembre, c'est quelque chose qui a peut être changé.

Les aspirateurs sont bien bufferisés par osm23 qui limite les req/s et qui active une jail fail2ban pour ceux qui ne respectent pas les 429 qu'on leur renvoie.

De quels plugins postgres tu parles ? Ceux pour Munin ?

Le 24 mai 2018 à 02:47, Marc-marc-marc notifications@github.com a écrit :

munin-master coupé sur osm13

lag : je ne parlais pas du lag après une coupure de service où là effectivement il vaut mieux éviter d'invalider plusieurs fois des tuiles (suffit de changer le paramètre après une grosse coupure ou couper renderd le temps de récupérer le retard). Je parlais du fait qu'en permanence osm13 subissait jusqu'à hier tous les jours des pic de 4h de lag. http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/ openstreetmap.fr/osm13.openstreetmap.fr/osm_replication_lag_osm2pgsql-day. png le lag a disparu après la modif d'hier. J'ai refais un test ce soir en saturer le serveur (exécution d'un render_list supplémentaire sur 12 threads), le lag de synchronisation est immédiat. Je propose de reporter la question maxInterval à + tard et de s'attaquer d'abord à la cause.

cache nginx sur osm13 : ne serrait-ce pas l'occasion de supprimer ce reliquat du passé ?

  • un peu d'html pour tile.openstreetmap.fr : on pourrait le servir comme les tuiles (cache osm23-rezopole -> osm13-apache)
  • un peu de download/export : actuellement nginx ne fait que transmettre ces requêtes à apache, donc on peux aussi les servir en direct depuis apache (et + tard migrer cela sur le serveur download) cela simplifierait la config et supprimerait le surcoût ram/cpu de cette surcouche.

attention à l'interprétation de la charge CPU : avec 12 cœurs CPU / 24 HT, une utilisation actuelle > ~1200% sature le cpu. l'HT peux apporter un gain de ~10% mais pas doubler la charge utile cpu.

Pour les tuiles, même 1.8 metatuiles/sec de novembre est pour moi bien faible comparé à 10 metatuiles/sec de scorch @ osm.org https://munin.openstreetmap.org/openstreetmap/scorch. openstreetmap/index.html http://munin.openstreetmap.fr/openstreetmap.fr/osm13. openstreetmap.fr/index.html ce qui frappe dans ce comparatif (si on ignore la différence du nombre de thread apache)

  • osm13 a 12 cœurs CPU et 500 processus
  • scorch a 8 cœurs CPU physique et 300 processus donc scorch va au moins 5x + vite avec presque 2 fois moins de processus. je propose de tester avec le multi-thread désactivé pour postgress parce que si on en a 11 requêtes en //, on ne gagne probablement rien a parallélisée chaque requête

il manque peut-être des index sur la bdd

aspirateur de tuile : on en a vu un hier, mais vu que cela m'impacte pas le débit de rendu des tuiles, je remettrait cela à + tard. sauf qu'il faudrait éviter de servir l'aspirateur depuis osm13 (cfr point 3 ci dessus)

la majorité des plugins postgress ne fonctionnent pas sur osm13. ils n'arrivent pas à trouver la version de postgress. j'ai réussis à en corriger 2 en supprimant le check de version ou le code pour les versions 8.x mais les autres ne vont pas.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/osm-fr/infrastructure/issues/27#issuecomment-391549896, or mute the thread https://github.com/notifications/unsubscribe-auth/ABJZ7Fzt4Gt-KJ9MrBizieHBbu5PkGb6ks5t1gMTgaJpZM4S7fcN .

-- Christian Quest - OpenStreetMap France

Marc-marc-marc commented 6 years ago

lag du à la charge : le fait que la maj se désactive due à l'excès de charge montre bien que la limitation de la charge hors maj db n'a pas une config optimale. par ex j'ai constaté qu'on a par moment un excès de charge du aux crons. j'ai vu plusieurs tâches render_list simultanées lancés en cron l'un lancé par /var/spool/cron/crontabs/osm2pgsql avec 10 ou 12 threads d'autres par /home/cquest/osm-cron.sh avec potentiellement 60 threads simultanés les heures de lancement ne sont pas les mêmes mais vu qu'elles peuvent dire des heures, cela finit par se chevaucher. cela mérite d'être plus raisonnable en nombre de thread et/ou lancer par batch et/ou killer à une certaine heure

nginx @ osm13 : l'impact en perf n'est sûrement pas énorme mais c'est toujours cela de pris. L'impact le plus important est la lisibilité de la conf. Avoir plein de petite chose pas totalement nécessaire ne facilite pas les choses.

aspirateur : ceux qui ne passent pas par osm23 mais qui accèdent à osm13 en direct du à l'erreur de conf du vhost ne semblent pas subir de limitation. cfr les pics 50 req simultanées sur le graph munin. D’où la proposition de supprimer cette porte dérobée. Ou moins bien : dupliquer la conf anti abus d'osm23 vers osm13.

cpu : un excès de render_list + chaque thread qui peux faire des requêtes db pouvant chacune demander le parallélisme + 128 threads pour le parallélisme io + les aspirateurs en direct + le manque de cache sur osm23 qui fait qu'on sert inutilement un grand nombre de requête/sec de tuile non modifiée... Au final, cela ne peux que ultra saturer.

plugins postgres : oui je parle des plugins munin

Voici un "proof of concept" de l'influence de l’excès de thread sur le débit de rendu de tuile : En journée, on tourne vers ~1metatuile/sec en bourrant le serveur au maximum. La nuit le serveur ne fait plus grand chose, j'ai donc utilisé ce créneau horaire pour faire un test de ce qu'on peux obtenir comme débit lorsqu'on n'est pas dans la situation d'excès. J'ai lancé render_list avec UN thread de rendu et obtenu 3 metatuiles/sec càd 3x plus de débit (le bleu) que celui de la journée http://munin.openstreetmap.fr/munin-cgi/munin-cgi-graph/openstreetmap.fr/osm13.openstreetmap.fr/renderd_processed-day.png

est-ce que je peux mettre graduellement en place les modifs proposées ou tu restes frileux par rapport à celles-ci ?

yohanboniface commented 6 years ago

est-ce que je peux mettre graduellement en place les modifs proposées ou tu restes frileux par rapport à celles-ci ?

À mon avis, tout ce qui est "rollbackable" facilement se teste.

/me tenté d'écrire rockandrollbackable :p

yohanboniface commented 6 years ago

@cquest ça vaut peut-être le coup de résumer ce que t'as fait sur osm13 récemment? Je crois que ça a corrigé pas mal de soucis?

cquest commented 6 years ago

Je n'ai pas encore le fin mot de l'histoire, mais c'est lié à la version de renderd (et donc aussi de mapnik).

J'utilisais une version compilée maison, et là j'ai repris celle du ppa osmadmins utilisés sur les serveurs osm.org et du coup on retrouve des perf normales.

En bonus, il y a quelques index que j'ai ajouté pour accélérer des requêtes SQL du style humanitaire, je vais faire un dump de la structure pour en avoir une copie.

2018-07-11 10:47 GMT+02:00 Yohan Boniface notifications@github.com:

@cquest https://github.com/cquest ça vaut peut-être le coup de résumer ce que t'as fait sur osm13 récemment? Je crois que ça a corrigé pas mal de soucis?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/osm-fr/infrastructure/issues/27#issuecomment-404093366, or mute the thread https://github.com/notifications/unsubscribe-auth/ABJZ7EXB32tTUFAbSq9ysyGmy6ixz8p3ks5uFbutgaJpZM4S7fcN .

-- Christian Quest - OpenStreetMap France

yohanboniface commented 6 years ago

J'utilisais une version compilée maison, et là j'ai repris celle du ppa osmadmins utilisés sur les serveurs osm.org et du coup on retrouve des perf normales.

Ah, je note le ppa pour pianoforte :)

cquest commented 5 years ago

Je ferme... les perfs sont à nouveau normales à rouvrir si besoin