Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Le 07/11/2017 à 10:00, gergero a écrit :

> Ils sont ici: http://osm13.openstreetmap.fr/~cquest/routes/
> 

"nouveau" que je suis, je découvre effectivement ces outils.

Peut-on lancer une mise à jour des fichiers d'écart en csv, ou la mise 
à jour se fait-elle automatiquement ?


Le calcul est fait chaque nuit (je viens de réactiver le cron nocturne).


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[gergero]

> Ils sont ici: http://osm13.openstreetmap.fr/~cquest/routes/
> 

"nouveau" que je suis, je découvre effectivement ces outils.

Peut-on lancer une mise à jour des fichiers d'écart en csv, ou la mise à 
jour se fait-elle automatiquement ?


Am 06.11.2017 um 08:03 schrieb Christian Quest:

Ces outils ne datent pas d'hier mais:
- pour les "anciens" on les oublie car on ne les utilise pas au quotidien
- pour les "nouveaux" on les découvre parce qu'on n'en parle pas souvent

Ces fichiers d'écarts sont effectivement faciles à traiter en complément 
de la couche Route500.


Il y a aussi les analyses osmose faites à base du Route500 qui 
permettent de repérer les incohérences: 
http://osmose.openstreetmap.fr/fr/map/#item=7170=2=15=48.12115=2.20363=Mapnik=T



QA...

C'est bon, le rendu QA est de retour et en turbo !
Le calcul des premiers zoom (6 à 8) ne prends désormais que quelques 
secondes :)


C'est beau de voir qu'il est de moins en moins coloré... les points 
magenta indiquant des routes potentiellement manquantes se sont bien 
réduits en 4 ans !
Il y a des nids à dégommer en Normandie, Aquitaine, PACA et au sud 
d'Orléans...




Le 5 novembre 2017 à 20:07, Francescu GAROBY > a écrit :


Merci Christian pour ces fichiers CSV, fort pratiques !
Ça m'a permis de "dézinguer du 0km" dans le Calvados, en
ajoutant/corrigeant les "ref" des routes qui n'en avaient pas, ou
qui avaient le mauvais (il s'agissait généralement de voie avec une
lettre manquante ou en minuscule, dans le tag "ref"), et qui étaient
donc considérées, dans le fichier CSV, comme faisaint 0km dans OSM.
Je nous recommande de faire ce travail pour tous les départements :
c'est pas très long (ça m'a pris plus d'une heure, pour le
Calvados), c'est facile et sans prise de tête (les routes existent,
c'est juste qu'elles n'ont pas le tag ref ou qu'il n'a pas la bonne
valeur) ! Et c'est d'autant plus simple qu'il existe la couche
Route500 dans JOSM, pour voir d'où à où vont les routes en question.
Un jeu d'enfant !

Francescu

Le 5 novembre 2017 à 17:45, Christian Quest > a écrit :

Un truc de plus remis en route sur osm13: les statistiques
d'écarts entre Route500 et OSM.

Pour rappel... ce sont des fichiers CSV départementaux, avec le
kilométrage dans OSM et Route500 de chaque route identifié par
son type et numéro (ex: D19, A6, N12).

Ils sont mis à jour chaque nuit et c'est la dernière version du
Route500 (2017) qui est utilisée.

Ils sont ici: http://osm13.openstreetmap.fr/~cquest/routes/



J'enchaîne avec "QA" et son rendu...

-- 
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr





-- 
Francescu


___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr





--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[JB]

Le 06/11/2017 à 08:03, Christian Quest a écrit :

QA...

C'est bon, le rendu QA est de retour et en turbo !
Le calcul des premiers zoom (6 à 8) ne prends désormais que quelques 
secondes :)


C'est beau de voir qu'il est de moins en moins coloré... les points 
magenta indiquant des routes potentiellement manquantes se sont bien 
réduits en 4 ans !
Il y a des nids à dégommer en Normandie, Aquitaine, PACA et au sud 
d'Orléans...

Tu peux rappeler la page pour le voir depuis un navigateur, hors JOSM ?
J'avais souvenir que c'était du coté de tile.openstreetmap.fr, mais ça 
n'a pas l'air d'être ça.

JB.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Ces outils ne datent pas d'hier mais:
- pour les "anciens" on les oublie car on ne les utilise pas au quotidien
- pour les "nouveaux" on les découvre parce qu'on n'en parle pas souvent

Ces fichiers d'écarts sont effectivement faciles à traiter en complément de
la couche Route500.

Il y a aussi les analyses osmose faites à base du Route500 qui permettent
de repérer les incohérences:
http://osmose.openstreetmap.fr/fr/map/#item=7170=2=15=48.12115=2.20363=Mapnik=T


QA...

C'est bon, le rendu QA est de retour et en turbo !
Le calcul des premiers zoom (6 à 8) ne prends désormais que quelques
secondes :)

C'est beau de voir qu'il est de moins en moins coloré... les points magenta
indiquant des routes potentiellement manquantes se sont bien réduits en 4
ans !
Il y a des nids à dégommer en Normandie, Aquitaine, PACA et au sud
d'Orléans...



Le 5 novembre 2017 à 20:07, Francescu GAROBY  a écrit :

> Merci Christian pour ces fichiers CSV, fort pratiques !
> Ça m'a permis de "dézinguer du 0km" dans le Calvados, en
> ajoutant/corrigeant les "ref" des routes qui n'en avaient pas, ou qui
> avaient le mauvais (il s'agissait généralement de voie avec une lettre
> manquante ou en minuscule, dans le tag "ref"), et qui étaient donc
> considérées, dans le fichier CSV, comme faisaint 0km dans OSM.
> Je nous recommande de faire ce travail pour tous les départements : c'est
> pas très long (ça m'a pris plus d'une heure, pour le Calvados), c'est
> facile et sans prise de tête (les routes existent, c'est juste qu'elles
> n'ont pas le tag ref ou qu'il n'a pas la bonne valeur) ! Et c'est d'autant
> plus simple qu'il existe la couche Route500 dans JOSM, pour voir d'où à où
> vont les routes en question. Un jeu d'enfant !
>
> Francescu
>
> Le 5 novembre 2017 à 17:45, Christian Quest  a
> écrit :
>
>> Un truc de plus remis en route sur osm13: les statistiques d'écarts entre
>> Route500 et OSM.
>>
>> Pour rappel... ce sont des fichiers CSV départementaux, avec le
>> kilométrage dans OSM et Route500 de chaque route identifié par son type et
>> numéro (ex: D19, A6, N12).
>>
>> Ils sont mis à jour chaque nuit et c'est la dernière version du Route500
>> (2017) qui est utilisée.
>>
>> Ils sont ici: http://osm13.openstreetmap.fr/~cquest/routes/
>>
>>
>> J'enchaîne avec "QA" et son rendu...
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Francescu
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Francescu GAROBY]

Merci Christian pour ces fichiers CSV, fort pratiques !
Ça m'a permis de "dézinguer du 0km" dans le Calvados, en
ajoutant/corrigeant les "ref" des routes qui n'en avaient pas, ou qui
avaient le mauvais (il s'agissait généralement de voie avec une lettre
manquante ou en minuscule, dans le tag "ref"), et qui étaient donc
considérées, dans le fichier CSV, comme faisaint 0km dans OSM.
Je nous recommande de faire ce travail pour tous les départements : c'est
pas très long (ça m'a pris plus d'une heure, pour le Calvados), c'est
facile et sans prise de tête (les routes existent, c'est juste qu'elles
n'ont pas le tag ref ou qu'il n'a pas la bonne valeur) ! Et c'est d'autant
plus simple qu'il existe la couche Route500 dans JOSM, pour voir d'où à où
vont les routes en question. Un jeu d'enfant !

Francescu

Le 5 novembre 2017 à 17:45, Christian Quest  a
écrit :

> Un truc de plus remis en route sur osm13: les statistiques d'écarts entre
> Route500 et OSM.
>
> Pour rappel... ce sont des fichiers CSV départementaux, avec le
> kilométrage dans OSM et Route500 de chaque route identifié par son type et
> numéro (ex: D19, A6, N12).
>
> Ils sont mis à jour chaque nuit et c'est la dernière version du Route500
> (2017) qui est utilisée.
>
> Ils sont ici: http://osm13.openstreetmap.fr/~cquest/routes/
>
>
> J'enchaîne avec "QA" et son rendu...
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Un truc de plus remis en route sur osm13: les statistiques d'écarts entre
Route500 et OSM.

Pour rappel... ce sont des fichiers CSV départementaux, avec le kilométrage
dans OSM et Route500 de chaque route identifié par son type et numéro (ex:
D19, A6, N12).

Ils sont mis à jour chaque nuit et c'est la dernière version du Route500
(2017) qui est utilisée.

Ils sont ici: http://osm13.openstreetmap.fr/~cquest/routes/


J'enchaîne avec "QA" et son rendu...

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Petit chantier du soir: j'ai mis à jour la BD Carthage qui sert à la couche
"hydro"  avec la dernière version dispo... 2014.

Pour mémoire...
https://wiki.openstreetmap.org/wiki/WikiProject_France/BDCarthage

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Le 03/11/2017 à 14:28, marc marc a écrit :

Merci pour tout le boulot effectué

Le 03. 11. 17 à 13:56, Christian Quest a écrit :

Reste à remettre en route des services annexes, liés à osmose ou
quelques exports quotidiens.

tu veux dire qu'une partie d'osmose est impacté ? si oui quoi ?


Mes petites analyses qui sont calculées par osm13... rien de très gênant 
(la preuve personne n'a remarqué).


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[marc marc]

Merci pour tout le boulot effectué

Le 03. 11. 17 à 13:56, Christian Quest a écrit :
> Reste à remettre en route des services annexes, liés à osmose ou 
> quelques exports quotidiens.

tu veux dire qu'une partie d'osmose est impacté ? si oui quoi ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Ça y est, les tuiles HOT sont de retour !

J'ai un peu galéré à cause des mises à jour des différents outils, en 
particulier mapnik qui est passé de la version 2 à la 3.


Le rendu HOT était TRES LENT depuis la mise à jour. Pour une même 
métatuile, le rendu HOT mettait 100s là où le rendu OpenRiverBoatMap 
mettait 2s !


Tout cela venait de la couche de dessin des limites administratives à 
cause d'un changement de comportement de mapnik qui ne "clipe" plus 
comme avant... ce qui a demandé par mal d'exploration !


Reste à remettre en route des services annexes, liés à osmose ou 
quelques exports quotidiens.



Le 01/11/2017 à 09:08, Christian Quest a écrit :
Quelques nouvelles du chantier: fin d'import du planet... il y a 
maintenant 8 jours de retard à rattraper...


Pendant ce temps, je m'attaque à la remise en route du rendu car il y 
a quelques trucs à reconfigurer car j'ai mis à jour pas mal de choses 
sur ce serveur (l'OS, mais aussi postgres passé en version 10, on 
était en 9.3).


Un peu de tuning à faire et ça repartira, j'espère encore mieux qu'avant !



Le 31 octobre 2017 à 08:02, Gaël Simon > a écrit :


Merci Christian pour ta disponibilité

Gaël

Le 30 oct. 2017 à 22:38, Christian Quest > a écrit :

Je lui ait demandé, mais ce coquin ne veut pas répondre !

Plus sérieusement, munin montre qu'il y a eu un pic sur la
latence, puis plus rien, kernel HS, machine bloquée.

Branché en USB sur mon laptop, il n'est pas détecté. Je ne pense
pas que ce soit un problème d'age de la mémoire flash, on était à
60% restant de durée de vie d'après le graph SMART de munin.


Le 30 octobre 2017 à 22:12, > a écrit :

Sait-on pourquoi il a lâché ?

Merci pour la réactivité.

Jean-Yvon


Le 30/10/2017 à 21:59, Christian Quest -
cqu...@openstreetmap.fr  a écrit :

SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04),
ré-import base planet en cours...

Le 30 octobre 2017 à 11:28, Christian Quest
> a
écrit :

Le 28/10/2017 à 13:04, Christian Quest a écrit :

Depuis cette nuit, 3h52...

Pas de réponse aux ping, je contacte free pour voir si
il y a eu un pépin...

Du coup, plus de tuiles HOT

-- 
Christian Quest - OpenStreetMap France


Serveur planté grave (rien à l'écran, voyant du clavier
qui ne réagissent plus, kernel ?)... free l'a
éteint/rallumé et il a rebooté.

Reboot ok, mais il semble y avoir un problème avec le
deuxième SSD, celui de 1To qui contient la base
postgresql qui ne monte pas.

En fait, il n'est pas détecté, mais la carte PCIe sur
lequel il est branché est bien visible dans lspci et lshw

Possible que le SSD lui même soit HS... ce qui veut dire
que je vais devoir y aller, le changer.

Ça tombe bien j'ai remplacé le SSD de mon laptop ce
week-end et libéré un SSD 840 EVO de 1To que je peux
mettre à la place.


Je viens de rebooter une seconde fois la machine et SSD
toujours pas là...


Conséquences:

- la base postgres est indisponible

- les tuiles ne peuvent plus être calculées

Par contre:

- les tuiles en cache mod_tile sont bien disponibles
(elles sont sur l'autre SSD) et donc servies même si
elles ne sont pas fraiches


Donc service dégradé, mais service quand même.


Actions...

- remplacer le SSD

- re-importer la planet...

- en profiter pour mettre à jour toute la machine (ubuntu
un peu ancien dessus)


-- 
Christian Quest - OpenStreetMap France





-- 
Christian Quest - OpenStreetMap France



___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr





-- 
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Quelques nouvelles du chantier: fin d'import du planet... il y a maintenant
8 jours de retard à rattraper...

Pendant ce temps, je m'attaque à la remise en route du rendu car il y a
quelques trucs à reconfigurer car j'ai mis à jour pas mal de choses sur ce
serveur (l'OS, mais aussi postgres passé en version 10, on était en 9.3).

Un peu de tuning à faire et ça repartira, j'espère encore mieux qu'avant !



Le 31 octobre 2017 à 08:02, Gaël Simon  a écrit :

> Merci Christian pour ta disponibilité
>
> Gaël
>
> Le 30 oct. 2017 à 22:38, Christian Quest  a
> écrit :
>
> Je lui ait demandé, mais ce coquin ne veut pas répondre !
>
> Plus sérieusement, munin montre qu'il y a eu un pic sur la latence, puis
> plus rien, kernel HS, machine bloquée.
>
> Branché en USB sur mon laptop, il n'est pas détecté. Je ne pense pas que
> ce soit un problème d'age de la mémoire flash, on était à 60% restant de
> durée de vie d'après le graph SMART de munin.
>
>
> Le 30 octobre 2017 à 22:12,  a écrit :
>
>> Sait-on pourquoi il a lâché ?
>>
>> Merci pour la réactivité.
>>
>> Jean-Yvon
>>
>> Le 30/10/2017 à 21:59, Christian Quest - cqu...@openstreetmap.fr a
>> écrit :
>>
>> SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04), ré-import base
>> planet en cours...
>>
>> Le 30 octobre 2017 à 11:28, Christian Quest  a
>> écrit :
>>
>>> Le 28/10/2017 à 13:04, Christian Quest a écrit :
>>>
>>> Depuis cette nuit, 3h52...
>>>
>>> Pas de réponse aux ping, je contacte free pour voir si il y a eu un
>>> pépin...
>>>
>>> Du coup, plus de tuiles HOT
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> Serveur planté grave (rien à l'écran, voyant du clavier qui ne
>>> réagissent plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.
>>>
>>> Reboot ok, mais il semble y avoir un problème avec le deuxième SSD,
>>> celui de 1To qui contient la base postgresql qui ne monte pas.
>>>
>>> En fait, il n'est pas détecté, mais la carte PCIe sur lequel il est
>>> branché est bien visible dans lspci et lshw
>>>
>>> Possible que le SSD lui même soit HS... ce qui veut dire que je vais
>>> devoir y aller, le changer.
>>>
>>> Ça tombe bien j'ai remplacé le SSD de mon laptop ce week-end et libéré
>>> un SSD 840 EVO de 1To que je peux mettre à la place.
>>>
>>>
>>> Je viens de rebooter une seconde fois la machine et SSD toujours pas
>>> là...
>>>
>>>
>>> Conséquences:
>>>
>>> - la base postgres est indisponible
>>>
>>> - les tuiles ne peuvent plus être calculées
>>>
>>> Par contre:
>>>
>>> - les tuiles en cache mod_tile sont bien disponibles (elles sont sur
>>> l'autre SSD) et donc servies même si elles ne sont pas fraiches
>>>
>>>
>>> Donc service dégradé, mais service quand même.
>>>
>>>
>>> Actions...
>>>
>>> - remplacer le SSD
>>>
>>> - re-importer la planet...
>>>
>>> - en profiter pour mettre à jour toute la machine (ubuntu un peu ancien
>>> dessus)
>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Gaël Simon]

Merci Christian pour ta disponibilité

Gaël

Le 30 oct. 2017 à 22:38, Christian Quest  a écrit :

Je lui ait demandé, mais ce coquin ne veut pas répondre !

Plus sérieusement, munin montre qu'il y a eu un pic sur la latence, puis plus 
rien, kernel HS, machine bloquée.

Branché en USB sur mon laptop, il n'est pas détecté. Je ne pense pas que ce 
soit un problème d'age de la mémoire flash, on était à 60% restant de durée de 
vie d'après le graph SMART de munin.


> Le 30 octobre 2017 à 22:12,  a écrit :
> Sait-on pourquoi il a lâché ?
> 
> Merci pour la réactivité.
> 
> Jean-Yvon
> 
>> Le 30/10/2017 à 21:59, Christian Quest   - cqu...@openstreetmap.fr a 
>> écrit :
>> SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04), ré-import base 
>> planet en cours...
>> 
>>> Le 30 octobre 2017 à 11:28, Christian Quest  a 
>>> écrit :
 Le 28/10/2017 à 13:04, Christian Quest a écrit :
 Depuis cette nuit, 3h52...
 
 Pas de réponse aux ping, je contacte free pour voir si il y a eu un 
 pépin...
 
 Du coup, plus de tuiles HOT
 
 -- 
 Christian Quest - OpenStreetMap France
>>> 
>>> Serveur planté grave (rien à l'écran, voyant du clavier qui ne réagissent 
>>> plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.
>>> 
>>> Reboot ok, mais il semble y avoir un problème avec le deuxième SSD, celui 
>>> de 1To qui contient la base postgresql qui ne monte pas.
>>> En fait, il n'est pas détecté, mais la carte PCIe sur lequel il est branché 
>>> est bien visible dans lspci et lshw
>>> 
>>> Possible que le SSD lui même soit HS... ce qui veut dire que je vais devoir 
>>> y aller, le changer.
>>> 
>>> Ça tombe bien j'ai remplacé le SSD de mon laptop ce week-end et libéré un 
>>> SSD 840 EVO de 1To que je peux mettre à la place.
>>> 
>>> 
>>> Je viens de rebooter une seconde fois la machine et SSD toujours pas là...
>>> 
>>> Conséquences:
>>> 
>>> - la base postgres est indisponible
>>> 
>>> - les tuiles ne peuvent plus être calculées
>>> 
>>> Par contre:
>>> 
>>> - les tuiles en cache mod_tile sont bien disponibles (elles sont sur 
>>> l'autre SSD) et donc servies même si elles ne sont pas fraiches
>>> 
>>> 
>>> Donc service dégradé, mais service quand même.
>>> 
>>> 
>>> Actions...
>>> 
>>> - remplacer le SSD
>>> 
>>> - re-importer la planet...
>>> 
>>> - en profiter pour mettre à jour toute la machine (ubuntu un peu ancien 
>>> dessus)
>>> 
>>> 
>>> -- 
>>> Christian Quest - OpenStreetMap France
>> 
>> 
>> 
>> -- 
>> Christian Quest - OpenStreetMap France
>> 
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Philippe Verdy]

Certains SSD ne mesurent que la qualité de l'espace de stockage des pages
de mémoire NAND, mais pas celui de la mémoire de tags (une mémoire un peu
plus rapide qui établit la correspondance entre secteurs physiques et
secteur logiques ou indiquent que le secteur est trimmé) et la bitmap des
pages trimmées (prêtes déjà à écrire) ou étant marquées comme à trimmer
(contenant encore les anciennes données d'un secteur logique qui a été
modié et écrit sur un autre secteur physique). Selon les SSD, ces espaces
supplémentaires ne sont pas toujours en mémoire NAND directement mais
dispose d'un frontal en registres CMOS, voire en RAM classique, destiné
ensuite à être transcrite en cas d'urgence (problème d'alimentation
détecté) dans des pages de mémoire NAND déjà allouée et trimmée (à l'aide
d'une réserve d'énergie sur leur carte mère sous forme de capas).
Les technologies de SSD varient selon les constructeurs (et aussi selon les
séries et l'usage auquel le SSD a été destiné et le prix pour les vendre)
sur la façon de recycler et trimmer les secteurs logiques et utiliser leur
pool de façon aléatoire pour éviter une fin de vie prématurée sur certains
secteurs de mémoire physiques. SMART n'indique pas forcément tout et le
firmware intégré qui gère ça est presque toujours propriétaire.

Les SSD pour laptops ne sont pas réputés pour être aussi fiables que ceux
pour serveurs qui ont plusieurs stratégies pour prévenir les pannes ou les
corriger, et peuvent intégrer des pools de mémoire NAND en résere plus
importants: c'est pour ça qu'un SSD vendu comme faisant 128Go en fait
souvent bien moins en capacité logique (celle qu'on voit dans l'outil de
partitionnement), et ce n'est pas seulement à cause du formatage logique
dans une partition utilisable ou de l'espace nécessaire pour le système de
fichiers lui-même (tables de partition, secteurs de démarrage, FAT ou
bitmaps d'allocation, tables d'inodes, MFT, dossier racine et index divers,
journaux transactionnels, etc.).

Si ton SSD n'est plus visible par l'interface USB, ce peut être aussi une
panne de son interface USB (mais normalement on doit pouvoir la détacher et
accéder à son interface SATA). Les interfaces USB sont réputées pour être
fragiles, surtout en USB3: ça flanche facilement du côté de l'alimentation
USB, sur un des SMOS d'entrée (grillé) ou sur un condo de régulation (fuite
interne: on peut parfois le voir sur le sommet du condo, là où il y a la
croix gracée: elle s'est soulevée et des gaz s'en sont échappés, on peut
repérer une "odeur" âcre, un gonflement du condo, ou des traces brunâtres
autour des soudures, ou un craquement des gravures ou des vernis sur le
circuit imprimé).

Le connecteur USB lui-même peut être endommagé (les plastiques se fèlent
tout seul avec le temps et la chauffe sur des contacts non dorés qui se
sont oxydés). Normalement là où le serveur est installé par Free,
l'hygrométrie et la températeure devrait être régulée et il ne devrait pas
y avoir trop de poussière non plus pouvant altérer le refroidissement ou
les connecteurs. Mais sait-on jamais si les machines n'ont pas été
déplacées ou bousculées, ou des connecteurs un peu trop tirés par erreur en
manipulant les matériels voisins dans les armoires? Normalement les câbles
devraient tous être bien rangés et fixés à l'armoire et étiquettés pour
éviter ce genre de fausse manip dans ces endroits où il y a beaucoup de
matériels qui peuvent changer régulièremlent.


Le 30 octobre 2017 à 22:38, Christian Quest  a
écrit :

> Je lui ait demandé, mais ce coquin ne veut pas répondre !
>
> Plus sérieusement, munin montre qu'il y a eu un pic sur la latence, puis
> plus rien, kernel HS, machine bloquée.
>
> Branché en USB sur mon laptop, il n'est pas détecté. Je ne pense pas que
> ce soit un problème d'age de la mémoire flash, on était à 60% restant de
> durée de vie d'après le graph SMART de munin.
>
>
> Le 30 octobre 2017 à 22:12,  a écrit :
>
>> Sait-on pourquoi il a lâché ?
>>
>> Merci pour la réactivité.
>>
>> Jean-Yvon
>>
>> Le 30/10/2017 à 21:59, Christian Quest - cqu...@openstreetmap.fr a
>> écrit :
>>
>> SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04), ré-import base
>> planet en cours...
>>
>> Le 30 octobre 2017 à 11:28, Christian Quest  a
>> écrit :
>>
>>> Le 28/10/2017 à 13:04, Christian Quest a écrit :
>>>
>>> Depuis cette nuit, 3h52...
>>>
>>> Pas de réponse aux ping, je contacte free pour voir si il y a eu un
>>> pépin...
>>>
>>> Du coup, plus de tuiles HOT
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>> Serveur planté grave (rien à l'écran, voyant du clavier qui ne
>>> réagissent plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.
>>>
>>> Reboot ok, mais il semble y avoir un problème avec le deuxième SSD,
>>> celui de 1To qui contient la base postgresql qui ne monte pas.
>>>
>>> En fait, il n'est pas détecté, mais la carte PCIe sur lequel il est
>>> branché est bien 

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Je lui ait demandé, mais ce coquin ne veut pas répondre !

Plus sérieusement, munin montre qu'il y a eu un pic sur la latence, puis
plus rien, kernel HS, machine bloquée.

Branché en USB sur mon laptop, il n'est pas détecté. Je ne pense pas que ce
soit un problème d'age de la mémoire flash, on était à 60% restant de durée
de vie d'après le graph SMART de munin.


Le 30 octobre 2017 à 22:12,  a écrit :

> Sait-on pourquoi il a lâché ?
>
> Merci pour la réactivité.
>
> Jean-Yvon
>
> Le 30/10/2017 à 21:59, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04), ré-import base
> planet en cours...
>
> Le 30 octobre 2017 à 11:28, Christian Quest  a
> écrit :
>
>> Le 28/10/2017 à 13:04, Christian Quest a écrit :
>>
>> Depuis cette nuit, 3h52...
>>
>> Pas de réponse aux ping, je contacte free pour voir si il y a eu un
>> pépin...
>>
>> Du coup, plus de tuiles HOT
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> Serveur planté grave (rien à l'écran, voyant du clavier qui ne réagissent
>> plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.
>>
>> Reboot ok, mais il semble y avoir un problème avec le deuxième SSD, celui
>> de 1To qui contient la base postgresql qui ne monte pas.
>>
>> En fait, il n'est pas détecté, mais la carte PCIe sur lequel il est
>> branché est bien visible dans lspci et lshw
>>
>> Possible que le SSD lui même soit HS... ce qui veut dire que je vais
>> devoir y aller, le changer.
>>
>> Ça tombe bien j'ai remplacé le SSD de mon laptop ce week-end et libéré un
>> SSD 840 EVO de 1To que je peux mettre à la place.
>>
>>
>> Je viens de rebooter une seconde fois la machine et SSD toujours pas là...
>>
>>
>> Conséquences:
>>
>> - la base postgres est indisponible
>>
>> - les tuiles ne peuvent plus être calculées
>>
>> Par contre:
>>
>> - les tuiles en cache mod_tile sont bien disponibles (elles sont sur
>> l'autre SSD) et donc servies même si elles ne sont pas fraiches
>>
>>
>> Donc service dégradé, mais service quand même.
>>
>>
>> Actions...
>>
>> - remplacer le SSD
>>
>> - re-importer la planet...
>>
>> - en profiter pour mettre à jour toute la machine (ubuntu un peu ancien
>> dessus)
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[osm . sanspourriel]

Sait-on pourquoi il a lâché ?

Merci pour la réactivité.

Jean-Yvon


Le 30/10/2017 à 21:59, Christian Quest - cqu...@openstreetmap.fr a écrit :
SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04), ré-import 
base planet en cours...


Le 30 octobre 2017 à 11:28, Christian Quest > a écrit :


Le 28/10/2017 à 13:04, Christian Quest a écrit :

Depuis cette nuit, 3h52...

Pas de réponse aux ping, je contacte free pour voir si il y a eu
un pépin...

Du coup, plus de tuiles HOT

-- 
Christian Quest - OpenStreetMap France


Serveur planté grave (rien à l'écran, voyant du clavier qui ne
réagissent plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.

Reboot ok, mais il semble y avoir un problème avec le deuxième
SSD, celui de 1To qui contient la base postgresql qui ne monte pas.

En fait, il n'est pas détecté, mais la carte PCIe sur lequel il
est branché est bien visible dans lspci et lshw

Possible que le SSD lui même soit HS... ce qui veut dire que je
vais devoir y aller, le changer.

Ça tombe bien j'ai remplacé le SSD de mon laptop ce week-end et
libéré un SSD 840 EVO de 1To que je peux mettre à la place.


Je viens de rebooter une seconde fois la machine et SSD toujours
pas là...


Conséquences:

- la base postgres est indisponible

- les tuiles ne peuvent plus être calculées

Par contre:

- les tuiles en cache mod_tile sont bien disponibles (elles sont
sur l'autre SSD) et donc servies même si elles ne sont pas fraiches


Donc service dégradé, mais service quand même.


Actions...

- remplacer le SSD

- re-importer la planet...

- en profiter pour mettre à jour toute la machine (ubuntu un peu
ancien dessus)


-- 
Christian Quest - OpenStreetMap France





--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

SSD remplacé... OS mis à jour (maintenant Ubuntu 16.04), ré-import base
planet en cours...

Le 30 octobre 2017 à 11:28, Christian Quest  a
écrit :

> Le 28/10/2017 à 13:04, Christian Quest a écrit :
>
> Depuis cette nuit, 3h52...
>
> Pas de réponse aux ping, je contacte free pour voir si il y a eu un
> pépin...
>
> Du coup, plus de tuiles HOT
>
> --
> Christian Quest - OpenStreetMap France
>
>
> Serveur planté grave (rien à l'écran, voyant du clavier qui ne réagissent
> plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.
>
> Reboot ok, mais il semble y avoir un problème avec le deuxième SSD, celui
> de 1To qui contient la base postgresql qui ne monte pas.
>
> En fait, il n'est pas détecté, mais la carte PCIe sur lequel il est
> branché est bien visible dans lspci et lshw
>
> Possible que le SSD lui même soit HS... ce qui veut dire que je vais
> devoir y aller, le changer.
>
> Ça tombe bien j'ai remplacé le SSD de mon laptop ce week-end et libéré un
> SSD 840 EVO de 1To que je peux mettre à la place.
>
>
> Je viens de rebooter une seconde fois la machine et SSD toujours pas là...
>
>
> Conséquences:
>
> - la base postgres est indisponible
>
> - les tuiles ne peuvent plus être calculées
>
> Par contre:
>
> - les tuiles en cache mod_tile sont bien disponibles (elles sont sur
> l'autre SSD) et donc servies même si elles ne sont pas fraiches
>
>
> Donc service dégradé, mais service quand même.
>
>
> Actions...
>
> - remplacer le SSD
>
> - re-importer la planet...
>
> - en profiter pour mettre à jour toute la machine (ubuntu un peu ancien
> dessus)
>
>
> --
> Christian Quest - OpenStreetMap France
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] osm13 ne répond(ait) plus...

[Christian Quest]

Le 28/10/2017 à 13:04, Christian Quest a écrit :

Depuis cette nuit, 3h52...

Pas de réponse aux ping, je contacte free pour voir si il y a eu un 
pépin...


Du coup, plus de tuiles HOT

--
Christian Quest - OpenStreetMap France


Serveur planté grave (rien à l'écran, voyant du clavier qui ne 
réagissent plus, kernel ?)... free l'a éteint/rallumé et il a rebooté.


Reboot ok, mais il semble y avoir un problème avec le deuxième SSD, 
celui de 1To qui contient la base postgresql qui ne monte pas.


En fait, il n'est pas détecté, mais la carte PCIe sur lequel il est 
branché est bien visible dans lspci et lshw


Possible que le SSD lui même soit HS... ce qui veut dire que je vais 
devoir y aller, le changer.


Ça tombe bien j'ai remplacé le SSD de mon laptop ce week-end et libéré 
un SSD 840 EVO de 1To que je peux mettre à la place.



Je viens de rebooter une seconde fois la machine et SSD toujours pas là...


Conséquences:

- la base postgres est indisponible

- les tuiles ne peuvent plus être calculées

Par contre:

- les tuiles en cache mod_tile sont bien disponibles (elles sont sur 
l'autre SSD) et donc servies même si elles ne sont pas fraiches



Donc service dégradé, mais service quand même.


Actions...

- remplacer le SSD

- re-importer la planet...

- en profiter pour mettre à jour toute la machine (ubuntu un peu ancien 
dessus)



--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr