performance tile.openstreetmap.fr

[Marc-marc-marc]

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 :

• il y a nginx visiblement inutilisé qui tourne et qui pourrait être arrêté.
• trop de processus en // ? 12 cœurs physique <> processus jusqu'à ~16
  https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/cpu.html
• osm.fr ne semble pas utiliser les mêmes versions que osm.org (cfr les nombreuses différences dans les moniteurs postgress sur munin)
  faudrait chercher la version postgress pour comparer
• le style osm.org a peut-être eu des améliorations d'efficacité, cfr le graphe qui semble indiquer un gain~50% sur un an
  https://munin.openstreetmap.org/openstreetmap/scorch.openstreetmap/renderd_zoom.html
  A voir si cela serrait pertinent ou pas de faire un rebase de l'upstream tout en y appliquant les spécifs osm-fr
• voir la cause du lag de réplication
• optimisation paramètre postgress ?
• pour éviter de ne rien faire pendant la nuit, il est possible d'augmenter la taille de la file dirty afin de traiter les modifs de la journée (dont actuellement une partie sont dropée) en différé au lieux d'attendre que quelqu'un redemande la tuile. on pourrait augmenter de +1000 par semaine jusqu'à avoir "de quoi travailler toute la nuit"
  Update render queue limits openstreetmap/mod_tile#152

[yohanboniface]

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]

@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]

ç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]

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 :

• réduire le nombre de rendu // d’actuellement 16 à 11 (le serveur de a 12 cœurs CPU) (cquest vient de le faire)
• couper munin master (le serveur osm13 crée les images et pages html pour munin alors que celle-ci sont déjà faite sur le serveur munin central)
• changer maxInterval = 14400 en maxInterval = 600 dans /home/osm2pgsql/osm2pgsql-import-tools/configuration.txt si les mesures précédentes ne suffisent pas pour éviter les lag de réplication

[cquest]

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]

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.

[cquest]

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 <#27 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJZ7Fzt4Gt-KJ9MrBizieHBbu5PkGb6ks5t1gMTgaJpZM4S7fcN> .

-- Christian Quest - OpenStreetMap France

[Marc-marc-marc]

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]

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]

@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]

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 <#27 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJZ7EXB32tTUFAbSq9ysyGmy6ixz8p3ks5uFbutgaJpZM4S7fcN> .

-- Christian Quest - OpenStreetMap France

[yohanboniface]

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]

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