performance tile.openstreetmap.fr #27
Comments
À ma connaissance il est utilisé en serveur de cache.
À 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. |
|
@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 ? |
|
ça me va... Avant de modifier quelque chose, préviens car c'est une stack un peu complexe. |
|
Merci. ybon tu as raison, ngnix est bien utilisé mais le cache a l'air d'être systématiquement inutile 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). premières propositions pour osm13 :
|
|
Je complète... le nginx sur osm13 servait de cache avant qu'on ait celui de lyon. 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. 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 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. |
|
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). cache nginx sur osm13 : ne serrait-ce pas l'occasion de supprimer ce reliquat du passé ?
attention à l'interprétation de la charge 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
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. la majorité des plugins postgress ne fonctionnent pas sur osm13. |
|
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
|
|
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. nginx @ osm13 : l'impact en perf n'est sûrement pas énorme mais c'est toujours cela de pris. 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. cpu : 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 : 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 |
|
@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? |
|
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
|
Ah, je note le ppa pour pianoforte :) |
|
Je ferme... les perfs sont à nouveau normales à rouvrir si besoin |
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 :
https://munin.openstreetmap.fr/openstreetmap.fr/osm13.openstreetmap.fr/cpu.html
faudrait chercher la version postgress pour comparer
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
Update render queue limits openstreetmap/mod_tile#152
The text was updated successfully, but these errors were encountered: