Re: Problème DNS qui commence à me brouter.....

2017-09-22 Par sujet Vincent 
Tu peux essayer de jouer avec le cible LOG ( ou autre ) d'iptables qui
te donnera l'uid et pid du processus faisant la requêtes.

Le 22/09/2017 à 08:08, David Martin a écrit :
> Bonjour,
> 
> J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.
> 
> J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
> que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
> coté postgres)... le problème c'est que nous avons du le remettre en service
> car le postgres continue à requéter dessus.
> 
> Impossible de trouver quel service requete dessus, mon resolv.conf n'à
> plus trace
> de ce vieux DNS.
> 
> J'ai cherché via netstat et l'ensemble des fonctions qu'il propose pour
> vérifier ça,
> lsof non plus ne me sort rien, il doit bien y avoir un service mais lequel.
> 
> J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
> rien...
> 
> Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
> d'erreur au démarrage
> du réseau qui me dit que l'ip est déjà occupée (celle du postgres),
> alors que je n'ai aucune
> machine (enfin je crois) qui à la même ip que mon serveur.
> 
> Je cherche encore ... si vous avez une idée, une astuce.
> 
> ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres, mais
> les perfs tombent
> et les accès sont ralenti pour l'ensemble des applications et
> utilisateurs... c'est zarb
> 
> Par quoi commenceriez vous ?
> 
> 
>  
> 
> -- 
> david martin
> 


-- 
EON Vincent
http://www.lws.fr
--
Siége social:
LIGNE WEB SERVICES
4, RUE GALVANI
75017 PARIS - FRANCE
---

Ce message et toute pièce jointe sont confidentiels et doivent être
protégés contre toute divulgation. Si vous n'êtes pas le destinataire de
ce message, merci de téléphoner ou d'envoyer un email à l'expéditeur, et
de détruire ce message et toute pièce jointe.

Re: Performance RAID instable

2017-09-22 Par sujet Seb 


Bonjour,


Les astuces que j'ai décrites permettent de maintenir les performances 
quand on écrit une grande quantité de données d'un coup ou bien une 
grandes quantité d'écritures aléatoirement réparties. C'est donné au cas 
où l'hypothèse que j'ai émise est la bonne, car ça colle très bien à ce 
que j'observe sur les supports amovibles. Reste à vérifier si 
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter un 
oeil par curiosité.


La comparaison me paraît limitée: sur mon système, je peux copier des 
centaines de Mo sans aucun problème à pleine vitesse puis, une heure plus 
tard, alors qu'il ne se passe rien de particulier sur la machine, observer 
que mes disques SSD sont tout à coup devenus plus lents que ma connexion

ADSL.

Je serais tenté de tester les disques avec l'outil de diagnostic 
constructeur, spécifique aux SSD, si il existe (je suis resté sur les 
magnétiques pour le stockage de masse (je veux dire autre que l'OS)).


Je serais fort surpris que le problème soit lié aux disques:

* un reboot résout le problème pour plusieurs heures;

* ces disques fonctionnaient parfaitement juste avant le passage en 
Debian 9, et incorrectement juste après;


* j'observe la chose sur deux machines, dont une neuve.

D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans 
période d'arrêt ou très courte.


Sous réserve d'avoir des disques SSD d'avance, ce qui n'est pas mon cas...


Seb.




Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :

Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
SSD
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
de
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une

écriture en

peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en
peu de
temps, mais ces moments ne coïncident pas avec la perte de
performance.
Des crontabs font des tas de jobs pour moi en sous-main, mais elles
les
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
disques
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
le
cas où quelqu'un aurait connaissance d'un changement dans la prise
en
charge de ce filesystem dans Debian, mais autrement, en lui-même, il
m'a
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout

cas

sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois
inverse:
empêcher la chute soudaine et inexpliquée des performances, plutôt
que
tirer autant de débit que possible d'un système fonctionnant
correctement
à la base :-)


Seb.



J'utilise Debian depuis une quinzaine d'années, sans problème de
RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font
chacune
du RAID1 sur deux disques SSD ont des performances disque qui se
dégradent
brutalement, sans raison apparente (rien trouvé dans syslog,
notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à
la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée

en

janvier aussi). Le PC était neuf, ses disques aussi. (C'est

toujours

la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis
plusieurs
années, a commencé à montrer les mêmes symptômes juste après son
passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais

dist-

upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017

était

donc en un
sens plus récente que la version de Debian 8 sur la machine de

bureau

en
juillet 2017.

* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à
plateaux.

* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent abyssales,

les

tableaux
RAID

Re : Re : Performance RAID instable

2017-09-22 Par sujet Thierry Bugier 
Je ne reproche rien à JFS, sinon d'être populaire :)

Vu le modèle, c'est clair ils ont TRIM, plus aucun disque ne doit être
produit sans cette techno. 

Les astuces que j'ai décrites permettent de maintenir les performances
quand on écrit une grande quantité de données d'un coup ou bien une
grandes quantité d'écritures aléatoirement réparties. C'est donné au
cas où l'hypothèse que j'ai émise est la bonne, car ça colle très bien
à ce que j'observe sur les supports amovibles. Reste à vérifier si
l'architecture dont j'ai parlé est la même sur les SSD. J'irai jeter un
oeil par curiosité.

Je serais tenté de tester les disques avec l'outil de diagnostic
constructeur, spécifique aux SSD, si il existe (je suis resté sur les
magnétiques pour le stockage de masse (je veux dire autre que l'OS)). A
faire seulement si vous avez des disques fiables sur lesquels migrer la
grappe.

D'ailleurs avec LVM ou RAID + hotswap ça peut se faire à chaud sans
période d'arrêt ou très courte. 

Le vendredi 22 septembre 2017 à 16:12 +0200, Seb a écrit :
> Hello,
> 
> 
> > Les SSD prennent ils en charge TRIM ?
> 
> Oui.
> 
> ~>sudo smartctl -i /dev/sda | grep ^"Device Model"
> Device Model: Samsung SSD 850 EVO 1TB
> 
> ~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
> Device Model: Samsung SSD 850 EVO 1TB
> 
> http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1
> T0B/EU/
> (^F TRIM)
> 
> (Je m'étais assuré de ce point quand j'avais acheté les disques.)
> 
> Je rappelle en outre que le même tableau RAID1 avec les mêmes disques
> SSD 
> a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage
> de 
> cette machine de Debian 8 à Debian 9.
> 
> > L'effondrement de performance ne serait-il consécutif à une
> écriture en 
> > peu de temps de quelques centaines de Mo, ou bien de nombreuses 
> > écritures très petites (< 32Ko environ) ?
> 
> Il m'arrive couramment de déplacer ou copier des centaines de Mo en
> peu de 
> temps, mais ces moments ne coïncident pas avec la perte de
> performance. 
> Des crontabs font des tas de jobs pour moi en sous-main, mais elles
> les 
> faisaient aussi sous Debian 8.
> 
> > Je n'utilise pas JFS, mais a t il été optimisé si possible pour 
> > respecter les contraintes techniques de ce genre de support ?
> 
> J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des
> disques 
> seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème 
> comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour
> le 
> cas où quelqu'un aurait connaissance d'un changement dans la prise
> en 
> charge de ce filesystem dans Debian, mais autrement, en lui-même, il
> m'a 
> toujours semblé très solide.
> 
> > Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout
> cas 
> > sur une clé USB bas de gamme ça fait des miracles.
> 
> Merci pour ces astuces d'optimisation. Mon problème est toutefois
> inverse: 
> empêcher la chute soudaine et inexpliquée des performances, plutôt
> que 
> tirer autant de débit que possible d'un système fonctionnant
> correctement 
> à la base :-)
> 
> 
> Seb.
> 
> 
> >> J'utilise Debian depuis une quinzaine d'années, sans problème de
> >> RAID
> >> jusqu'à présent. Mon souci actuel est que deux machines qui font
> >> chacune
> >> du RAID1 sur deux disques SSD ont des performances disque qui se
> >> dégradent
> >> brutalement, sans raison apparente (rien trouvé dans syslog,
> >> notamment).
> >> La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
> >> différence est si nette qu'une mesure grossière avec 'dd' suffit à
> >> la
> >> mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).
> >>
> >> * La machine à la maison en a été la première victime, dès son
> >> installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée
> en
> >> janvier aussi). Le PC était neuf, ses disques aussi. (C'est
> toujours
> >> la
> >> version stable de Debian que j'utilise.)
> >>
> >> * La machine de bureau, qui donnait entière satisfaction depuis
> >> plusieurs
> >> années, a commencé à montrer les mêmes symptômes juste après son
> >> passage de
> >> Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
> >> n'était pas
> >> une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
> >> n'était que
> >> partiellement à jour car j'utilise apt-get upgrade mais jamais
> dist-
> >> upgrade. La
> >> version de Debian 8 sur la machine à la maison en janvier 2017
> était
> >> donc en un
> >> sens plus récente que la version de Debian 8 sur la machine de
> bureau
> >> en
> >> juillet 2017.
> >>
> >> * Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
> >> rencontrer le
> >> problème, mais elles font toutes deux du RAID6 sur des disques à
> >> plateaux.
> >>
> >> * Les quatre machines utilisent exclusivement JFS.
> >>
> >> Je souligne que même quand les performances deviennent abyssales,
> les
> >> tableaux
> >> RAID fonctionnent. On peut par exemple copier un fichier ('cp').
> >>
> >> Redémarrer la

Re: Re : Performance RAID instable

2017-09-22 Par sujet Seb 


Hello,



Les SSD prennent ils en charge TRIM ?


Oui.

~>sudo smartctl -i /dev/sda | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

~>sudo smartctl -i /dev/sdb | grep ^"Device Model"
Device Model: Samsung SSD 850 EVO 1TB

http://www.samsung.com/fr/consumer/memory-storage/ssd/850-evo/MZ-75E1T0B/EU/
(^F TRIM)

(Je m'étais assuré de ce point quand j'avais acheté les disques.)

Je rappelle en outre que le même tableau RAID1 avec les mêmes disques SSD 
a fonctionné pendant longtemps sans aucun souci -- jusqu'au passage de 
cette machine de Debian 8 à Debian 9.


L'effondrement de performance ne serait-il consécutif à une écriture en 
peu de temps de quelques centaines de Mo, ou bien de nombreuses 
écritures très petites (< 32Ko environ) ?


Il m'arrive couramment de déplacer ou copier des centaines de Mo en peu de 
temps, mais ces moments ne coïncident pas avec la perte de performance. 
Des crontabs font des tas de jobs pour moi en sous-main, mais elles les 
faisaient aussi sous Debian 8.


Je n'utilise pas JFS, mais a t il été optimisé si possible pour 
respecter les contraintes techniques de ce genre de support ?


J'ai utilisé JFS sur des tas de machines depuis 10-15 ans, des disques 
seuls, des tableaux RAID1, 5 et 6, je n'ai jamais eu de problème 
comparable à celui que je constate aujourd'hui. J'ai signalé JFS pour le 
cas où quelqu'un aurait connaissance d'un changement dans la prise en 
charge de ce filesystem dans Debian, mais autrement, en lui-même, il m'a 
toujours semblé très solide.


Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas 
sur une clé USB bas de gamme ça fait des miracles.


Merci pour ces astuces d'optimisation. Mon problème est toutefois inverse: 
empêcher la chute soudaine et inexpliquée des performances, plutôt que 
tirer autant de débit que possible d'un système fonctionnant correctement 
à la base :-)



Seb.



J'utilise Debian depuis une quinzaine d'années, sans problème de
RAID
jusqu'à présent. Mon souci actuel est que deux machines qui font
chacune
du RAID1 sur deux disques SSD ont des performances disque qui se
dégradent
brutalement, sans raison apparente (rien trouvé dans syslog,
notamment).
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La
différence est si nette qu'une mesure grossière avec 'dd' suffit à
la
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).

* La machine à la maison en a été la première victime, dès son
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours
la
version stable de Debian que j'utilise.)

* La machine de bureau, qui donnait entière satisfaction depuis
plusieurs
années, a commencé à montrer les mêmes symptômes juste après son
passage de
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
n'était pas
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
n'était que
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-
upgrade. La
version de Debian 8 sur la machine à la maison en janvier 2017 était
donc en un
sens plus récente que la version de Debian 8 sur la machine de bureau
en
juillet 2017.

* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
rencontrer le
problème, mais elles font toutes deux du RAID6 sur des disques à
plateaux.

* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent abyssales, les
tableaux
RAID fonctionnent. On peut par exemple copier un fichier ('cp').

Redémarrer la machine restaure la performance normale. La performance
reste
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui
peut
arriver même quand il n'y a personne devant l'écran, en pleine nuit.

Je joins ci-dessous le résultat des commandes suivantes, lancées sur
la machine
de bureau (RAID1 sur sda+sdb):
smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb

Est-ce que ces comportements vous évoquent des souvenirs, ou des
pistes à
creuser ? Comment pourrais-je extraire du système des informations
sur
l'origine du problème ? Voyez-vous quels changements intervenus dans
la
Debian 8, après la release initiale, pourraient causer ce
comportement ?


Merci d'avance pour votre aide !
Seb.

PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me
sera
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-
coller
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la
commande
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la
commande
collée apparaît en inverse vidéo, un retour à la ligne a bien été
inséré (le
curseur est sur une nouvelle ligne), mais cela ne provoque pas
l'exécution de
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien
revenir à
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne
sais pas
ce qu'il faut

Re: Problème DNS qui commence à me brouter.....

2017-09-22 Par sujet Jonathan bartoua Schneider 
Hello,

Ton postgres aurait pas gardé les confs de resolvers dans son cache ?
Il y a des programmes qui font ça (genre apache).

Jonathan

Le 22 septembre 2017 à 14:29, G2PC  a écrit :

> Le 22/09/2017 à 08:08, David Martin a écrit :
>
> Bonjour,
>
> J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.
>
> J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
> que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
> coté postgres)... le problème c'est que nous avons du le remettre en
> service
> car le postgres continue à requéter dessus.
>
> Impossible de trouver quel service requete dessus, mon resolv.conf n'à
> plus trace
> de ce vieux DNS.
>
> J'ai cherché via netstat et l'ensemble des fonctions qu'il propose pour
> vérifier ça,
> lsof non plus ne me sort rien, il doit bien y avoir un service mais lequel.
>
> J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
> rien...
>
> Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
> d'erreur au démarrage
> du réseau qui me dit que l'ip est déjà occupée (celle du postgres), alors
> que je n'ai aucune
> machine (enfin je crois) qui à la même ip que mon serveur.
>
> Je cherche encore ... si vous avez une idée, une astuce.
>
> ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres, mais
> les perfs tombent
> et les accès sont ralenti pour l'ensemble des applications et
> utilisateurs... c'est zarb
>
> Par quoi commenceriez vous ?
> --
> david martin
>
> Je suis loin d'être le plus compétent en réseau pour t'apporter une
> réponse valable, je me jette à l'eau, qui sait.
>
> Lors de mon installation de Unbound, j'ai compris qu'il y a différentes
> façons de configurer son réseau, avec différents outils.
>
> Peut être déjà tenter de savoir si ton fichier resolv.conf est " statique
> ", ou, généré par un autre service, comme le programme resolvconf ?
>
> Mes quelques notes sur les DNS concernent Unbound, et, ne sont pas
> abouties, mais, peut être que cela peut t'aider avec de nouvelles pistes :
> https://www.visionduweb.eu/wiki/index.php?title=Changer_de_DNS
>
> Je ne peux pas t'aider plus, d'autres auront des réponses plus précises et
> adaptées.
>



-- 
bartoua est votre ami

Re : Performance RAID instable

2017-09-22 Par sujet Thierry Bugier 
Bonjour

Quelques questions:

Les SSD prennent ils en charge TRIM ?

L'effondrement de performance ne serait-il consécutif à une écriture en
peu de temps de quelques centaines de Mo, ou bien de nombreuses
écritures très petites (< 32Ko environ) ?

Je n'utilise pas JFS, mais a t il été optimisé si possible pour
respecter les contraintes techniques de ce genre de support ?

Il faut que je vérifie si ce qui suit s'applique aux SSD. En tout cas
sur une clé USB bas de gamme ça fait des miracles.

Les stockages "solide" ou "flash" connaissent la notion de bloc
d'effacement. C'est à dire que quand on écrit une donnée on va modifier
sur un de ces blocs, si la donnée écrite diffère d'un seul bit du
contenu préalablement enregistré, il faut effacer tout le bloc et le
réécrire entièrement. Une exception, si les tous bits devant être
modifiés passent de l'état 0 à l'état 1 et pas l'inverse.

Donc pour un seul bit, on peut se retrouver à écrire en réalité un bloc
 de l'ordre du Mo. Du gâchis en somme. 

J'ai eu à utiliser une clé USB ces dernières semaines pour transférer
quelques Go d'un PC à un autre. En optimisant le système de fichiers
ext4 (la clé étatn une bouse de supermarché) j'ai ou atteindre un débit
entre 15 et 20 Mo/s. Au delà de mes espérances pour le support que
j'avais.

L'astuce consiste à configurer le système de fichier pour écrire par
blocs de taille multiple du bloc d'effacement.

Pour trouver la  taille de ce bloc d'effacement, trouvez dans les
dépôts Debian le paquet flashbench. Le site donne des infos sur
l'interprétation des résultats: https://github.com/bradfa/flashbench

En cherchant une source pour expliquer l'optimisation d'un support
flash (usb ou SD) je retrouve sur la source qui m'a tout appris. Je la
redonne donc ici : https://blogofterje.wordpress.com/2012/01/14/optimiz
ing-fs-on-sd-card/

Elle explique aussi l'alignement des partitions, et le "segment size"
dont j'ai oublié de parler.

Dans le cas d'un RAID, il faudra faire des configurations similaires au
niveau de la grappe. C'est paramétrable et à l'époque des disques
magnétiques on optimisait déjà les performances en configurant finement
ses grappes. Un vieil exemple : http://monblog.system-linux.net/blog/20
11/07/02/modification-de-lalignement-disque-lors-de-linstallation-dune-
mandriva-2009-0/

Encore une fois, il faut vérifier si ça s'applique aux SSD, je pense
que oui, mais sans avoir de preuve pour l'instant. Je n'ai pas eu de
problème particulier en me contentant d'aligner mes partitions (il
supporte TRIM).



Le vendredi 22 septembre 2017 à 12:22 +0200, Seb a écrit :
> Bonjour !
> 
> 
> J'utilise Debian depuis une quinzaine d'années, sans problème de
> RAID 
> jusqu'à présent. Mon souci actuel est que deux machines qui font
> chacune 
> du RAID1 sur deux disques SSD ont des performances disque qui se
> dégradent 
> brutalement, sans raison apparente (rien trouvé dans syslog,
> notamment). 
> La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La 
> différence est si nette qu'une mesure grossière avec 'dd' suffit à
> la 
> mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).
> 
> * La machine à la maison en a été la première victime, dès son 
> installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en 
> janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours
> la 
> version stable de Debian que j'utilise.)
> 
> * La machine de bureau, qui donnait entière satisfaction depuis
> plusieurs 
> années, a commencé à montrer les mêmes symptômes juste après son
> passage de 
> Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce
> n'était pas 
> une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8
> n'était que 
> partiellement à jour car j'utilise apt-get upgrade mais jamais dist-
> upgrade. La 
> version de Debian 8 sur la machine à la maison en janvier 2017 était
> donc en un 
> sens plus récente que la version de Debian 8 sur la machine de bureau
> en 
> juillet 2017.
> 
> * Par ailleurs, j'ai passé deux autres machines en Debian 9 sans
> rencontrer le 
> problème, mais elles font toutes deux du RAID6 sur des disques à
> plateaux.
> 
> * Les quatre machines utilisent exclusivement JFS.
> 
> Je souligne que même quand les performances deviennent abyssales, les
> tableaux 
> RAID fonctionnent. On peut par exemple copier un fichier ('cp').
> 
> Redémarrer la machine restaure la performance normale. La performance
> reste 
> alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui
> peut 
> arriver même quand il n'y a personne devant l'écran, en pleine nuit.
> 
> Je joins ci-dessous le résultat des commandes suivantes, lancées sur
> la machine 
> de bureau (RAID1 sur sda+sdb):
> smartctl -t short /dev/sda
> smartctl -l selftest /dev/sda
> smartctl -t short /dev/sdb
> smartctl -l selftest /dev/sdb
> 
> Est-ce que ces comportements vous évoquent des souvenirs, ou des
> pistes à 
> creuser ? Comment pourrais-je extraire du

Re: Problème DNS qui commence à me brouter.....

2017-09-22 Par sujet G2PC 
Le 22/09/2017 à 08:08, David Martin a écrit :
> Bonjour,
>
> J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.
>
> J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
> que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
> coté postgres)... le problème c'est que nous avons du le remettre en
> service
> car le postgres continue à requéter dessus.
>
> Impossible de trouver quel service requete dessus, mon resolv.conf n'à
> plus trace
> de ce vieux DNS.
>
> J'ai cherché via netstat et l'ensemble des fonctions qu'il propose
> pour vérifier ça,
> lsof non plus ne me sort rien, il doit bien y avoir un service mais
> lequel.
>
> J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
> rien...
>
> Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
> d'erreur au démarrage
> du réseau qui me dit que l'ip est déjà occupée (celle du postgres),
> alors que je n'ai aucune
> machine (enfin je crois) qui à la même ip que mon serveur.
>
> Je cherche encore ... si vous avez une idée, une astuce.
>
> ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres,
> mais les perfs tombent
> et les accès sont ralenti pour l'ensemble des applications et
> utilisateurs... c'est zarb
>
> Par quoi commenceriez vous ?
> -- 
> david martin
Je suis loin d'être le plus compétent en réseau pour t'apporter une
réponse valable, je me jette à l'eau, qui sait.

Lors de mon installation de Unbound, j'ai compris qu'il y a différentes
façons de configurer son réseau, avec différents outils.

Peut être déjà tenter de savoir si ton fichier resolv.conf est "
statique ", ou, généré par un autre service, comme le programme resolvconf ?

Mes quelques notes sur les DNS concernent Unbound, et, ne sont pas
abouties, mais, peut être que cela peut t'aider avec de nouvelles pistes
: https://www.visionduweb.eu/wiki/index.php?title=Changer_de_DNS

Je ne peux pas t'aider plus, d'autres auront des réponses plus précises
et adaptées.

Performance RAID instable

2017-09-22 Par sujet Seb 


Bonjour !


J'utilise Debian depuis une quinzaine d'années, sans problème de RAID 
jusqu'à présent. Mon souci actuel est que deux machines qui font chacune 
du RAID1 sur deux disques SSD ont des performances disque qui se dégradent 
brutalement, sans raison apparente (rien trouvé dans syslog, notamment). 
La vitesse du tableau passe, en gros, de 600 Mo/s à 0,5 Mo/s. La 
différence est si nette qu'une mesure grossière avec 'dd' suffit à la 
mettre en évidence (dd if=/dev/zero of=dd.big bs=1k count=1).


* La machine à la maison en a été la première victime, dès son 
installation sous Debian 8 en janvier 2017 (Debian 8 téléchargée en 
janvier aussi). Le PC était neuf, ses disques aussi. (C'est toujours la 
version stable de Debian que j'utilise.)


* La machine de bureau, qui donnait entière satisfaction depuis plusieurs 
années, a commencé à montrer les mêmes symptômes juste après son passage de 
Debian 8 à Debian 9 en juillet 2017. Avant la réinstallation (ce n'était pas 
une migration de 8 à 9 ne nécessitant qu'un reboot), la Debian 8 n'était que 
partiellement à jour car j'utilise apt-get upgrade mais jamais dist-upgrade. La 
version de Debian 8 sur la machine à la maison en janvier 2017 était donc en un 
sens plus récente que la version de Debian 8 sur la machine de bureau en 
juillet 2017.


* Par ailleurs, j'ai passé deux autres machines en Debian 9 sans rencontrer le 
problème, mais elles font toutes deux du RAID6 sur des disques à plateaux.


* Les quatre machines utilisent exclusivement JFS.

Je souligne que même quand les performances deviennent abyssales, les tableaux 
RAID fonctionnent. On peut par exemple copier un fichier ('cp').


Redémarrer la machine restaure la performance normale. La performance reste 
alors stable pendant plusieurs heures. Puis elle s'écroule, ce qui peut 
arriver même quand il n'y a personne devant l'écran, en pleine nuit.


Je joins ci-dessous le résultat des commandes suivantes, lancées sur la machine 
de bureau (RAID1 sur sda+sdb):

smartctl -t short /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sdb
smartctl -l selftest /dev/sdb

Est-ce que ces comportements vous évoquent des souvenirs, ou des pistes à 
creuser ? Comment pourrais-je extraire du système des informations sur 
l'origine du problème ? Voyez-vous quels changements intervenus dans la 
Debian 8, après la release initiale, pourraient causer ce comportement ?



Merci d'avance pour votre aide !
Seb.

PS: si quelqu'un sait comment régler le p'tit problème suivant, ça me sera 
utile aussi: jusqu'à la Debian 8 incluse, quand je faisais un copier-coller 
d'une ligne entière depuis un xterm vers un xterm exécutant zsh, la commande 
s'exécutait dès l'étape coller. Depuis le passage à Debian 9, la commande 
collée apparaît en inverse vidéo, un retour à la ligne a bien été inséré (le 
curseur est sur une nouvelle ligne), mais cela ne provoque pas l'exécution de 
la commande, il faut encore que j'appuie sur Entrée. J'aimerais bien revenir à 
la situation précédente (pas besoin d'appuyer sur Entrée) mais je ne sais pas 
ce qu'il faut régler...


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#smartctl -l selftest /dev/sda
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining LifeTime(hours) 
LBA_of_first_error

# 1  Short offline   Completed without error   00% 17786  -
# 2  Short offline   Completed without error   00% 15666  -

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#smartctl -l selftest /dev/sdb
smartctl 6.6 2016-05-31 r4324 [i686-linux-4.9.0-3-686-pae] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining LifeTime(hours) 
LBA_of_first_error

# 1  Short offline   Completed without error   00% 16593  -

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10]

md3 : active raid1 sdb3[1] sda3[0]
  951464640 blocks super 1.2 [2/2] [UU]
  bitmap: 2/8 pages [8KB], 65536KB chunk

md2 : active raid1 sda1[0] sdb1[1]
  20955136 blocks super 1.2 [2/2] [UU]

unused devices:

Problème DNS qui commence à me brouter.....

2017-09-22 Par sujet David Martin 
Bonjour,

J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.

J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
coté postgres)... le problème c'est que nous avons du le remettre en service
car le postgres continue à requéter dessus.

Impossible de trouver quel service requete dessus, mon resolv.conf n'à plus
trace
de ce vieux DNS.

J'ai cherché via netstat et l'ensemble des fonctions qu'il propose pour
vérifier ça,
lsof non plus ne me sort rien, il doit bien y avoir un service mais lequel.

J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
rien...

Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
d'erreur au démarrage
du réseau qui me dit que l'ip est déjà occupée (celle du postgres), alors
que je n'ai aucune
machine (enfin je crois) qui à la même ip que mon serveur.

Je cherche encore ... si vous avez une idée, une astuce.

ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres, mais les
perfs tombent
et les accès sont ralenti pour l'ensemble des applications et
utilisateurs... c'est zarb

Par quoi commenceriez vous ?




-- 
david martin