Volume Iscis Monte A +/- 90%

[miltechbv]

Bonjours

Lorsque je lance l’ interface download station le Volume iSCIS monte A +/- 90% voir 100% et réduit les transferts en cour de l’ upload j' ai alors moins de 30 secondes pour voir le travaille mais juste le temps de les voir sans de les analyser, a la fermeture de l’ interface download station le Volume iSCIS retombe A 1% en 1 ou 2 minutes et mes upload remonte, je les contrôles par l interface de le freebox ou les stat du synology.

Dans paramètre j’ai mi Nb paires autorisée de 50 a 5 maintenant mai idem.

Téléchargement actif 0.

J ai un total de 250 filmes en partages.

DS412+ DSM 5.1-5004 4 disques de 2.73 To en Hybride RAID (SHR)

download station: 3.5-2638

Avez-vous une idée ou le même souci.

Merci.

Modifié le 2 décembre 2014 par miltechbv

[miltechbv]

Re bonjour pas de réponses.

Merci au moins de me signaler le comportement de download station et du Volume i Scis.

transfert total :

1 : download station ouvert sur l' écran pc.

2 : download station fermé sur l' écran pc.

Modifié le 30 novembre 2014 par miltechbv

[PetitGreg]

Bonjour miltechbv,

idem chez moi.

Pour l'usage important de Volume/iSCSI, c'est principalement en écriture de mon coté (en I/O comme taux de transfert), pas en lecture.

Complément : si on met les tâches BT en pause, retour à la normale, même en laissant le GUI ouvert.

J'ai fait un bug report le 24/11 à Syno (via https://myds.synology.com/support/support_form.php?lang=enu ). Le 28/11, on m'a demandé d'envoyer un Kernel log pour analyse.

Pas encore de retour, mais c'est un peu normal, c'est tout frais...
Je te tiendrais au courant si j'en sais d'avantage.

Cordialement.

[brunobruno69]

Mois aussi c est en écriture c' emmerdant pour voir les fichier qui tourne il disparaisse en mois de 30 seconde.

Bizar que nous ne somme que deux a réagir.

j ai voulu aussi faire un bug report mais ça doit être en anglais et mois nul.

Donc si tu peut me tenir au courant volontiers et merci d'avance.

[miltechbv]

ho pardon brunobruno69 = miltechbv deux compte sans mémé m en être rendu compte

[PetitGreg]

Bonjour à tous,

Premier retour du support :

- Ils n'ont rien trouver de significatif dans les logs (moi non plus, j'avais regardé en attendant. -pour infos, il y a quelques infos persos qui peuvent trainer dans les logs, mais aucun mots de passe, credentials ou informations critiques ne peuvent y être lu, donc pas de panique si Synology vous les demande- )
- Ils me demandent si ça arrive seulement quand on télécharge des Torrents, si ça arrive aussi quand on télécharge basiquement via HTTP.

Je leur explique que ça le fait dès qu'une tâche est active (mesurée entre 7 et 10% d'usage Volume/iSCSI par tâche).
Je leur ai précisé que l'usage Volume/iSCSI n'était quasi qu'en écriture, aussi bien en I/O comme en transfert.
Le problème apparait avec des téléchargements HTTP, FTP, Usenet et téléchargements/partages Torrent.
Seul les tâches actives impactent le système. Les tâches en pause ou terminées n'affectent pas le système.

Je leur ré-explique que ça arrive lorsque l'interface graphique utilisateur (GUI) est ouverte.

Au passage, je leur avais déjà expliquer que ça arrive aussi lorsqu'on lance l'application iOS.

J'ai expliqué aussi qu'entre temps :
- j'ai mis à jour DSM 5.1-5004 vers 5.1-5004 update 2 => sans changements.
- j'ai modifié la langue de l'interface de DSM de français à anglais => sans changements.

- j'ai supprimé l'intégralité des tâches enregistrées dans Download Station, purger le répertoire @download et désinstaller/réinstaller le package => sans changements. (j'ai bricolé d'autres trucs : réindexation, purges dans postgreSQL et création de nouveaux fichiers de conf. Mais ça n'a rien donné. Je ne veux pas perdre le support dans toutes les directions et qu'ils croient que je fais n'importe quoi de mon coté, alors je garde ces informations pour moi).
- j'ai testé le package Transmission en version 2.84 (provenant de synocommunity, package signé et conforme) et qu'il marche parfaitement, le daemon comme le GUI.

Je leur ai demandé s'il était possible d'avoir des logs plus verbeux ou d'accéder à un mode debug pour leurs packages officiels.

J'attends leur(s) retour(s) et vous tiens au courant.

Cordialement.

Modifié le 5 décembre 2014 par PetitGreg

[brunobruno69]

merci pour le retour d informations

[PetitGreg]

Je n'ai pas eu de retour de Synology, mais de mon coté, avec iotop, j'ai trouvé que c'était une requête UPDATE de postgreSQL liée à Download Station qui "mangeait" tout l'I/O.
J'ai transmis à Synology, on verra ce qu'ils répondront.

[brunobruno69]

ho mais tu est informaticien non !

merci encore ca avance.

[gaetan.cambier]

quel requete pose problème ?

[brunobruno69]

Une petite réflexion je sais pas ci ça sera utile :

Le problème existe quand la fenêtre DS est ouverte on est d’accord mais ci je la réduit donc encor en tache de fond juste sur la bar de notification on retrouve les ressources Iscsi libre.

donc peut être un problème de rafraîchissement de la page ? vous le savez peut être déjà ?

A plus.

Modifié le 8 décembre 2014 par brunobruno69

[PetitGreg]

@Gaetan Cambier
j'aimerai bien aussi connaitre cette requête précisément.
Il faudrait bricoler postgresql.conf pour qu'il log les requêtes, mais j'attends la réponse du support avant de prendre d'autres initiatives.
Déjà qu'installer des ipkg via un bootstrap, je ne suis pas sûr d'être encore dans les clous, alors je vais en rester là, surtout qu'il y a d'autres packages Syno qui ont leurs bases dans postgreSQL et que je n'ai pas envie de risquer d'en altérer le bon fonctionnement.

Hors sujet : A propos de postgreSQL, sais-tu pourquoi l'autovacuum est désactivé ? D'après les docs de postgreSQL, c'est un paramètre qui doit être activé, par défaut, pour le bon fonctionnement des bases (nettoyage et optimisation).

[gaetan.cambier]

j'avais lu encore à moitié, je croyeit que tu savait quelle requete c'etait :s

devrait mieux lire, ca serait bien

[PetitGreg]

Bien que iotop soit super pratique, il n'indique seulement que la commande relative à l'I/O.

Dans mon cas, c'était :
postgres: postgres download [local] UPDATE

On ne va pas se plaindre, c'est déjà très indicatif (processus, db, opération).

Voilà tout ce qu'on peut avoir avec iotop (http://guichaz.free.fr/iotop/) dans mon cas :

TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND

17739 be/4 postgres 0.00 B/s 511.71 K/s 0.00 % 87. % postgres: postgres download [local] UPDATE

@brunobruno69

Idem chez moi, gui lancé puis minimisé, retour à la normale pour Volume/iSCSI.

Modifié le 8 décembre 2014 par PetitGreg

[gaetan.cambier]

viens de tester, qd downloadstation est ouvert, ca ecrit sur le disk à + de 1mo/sec sur le iscsi

et dans top, on voit le postgresql en update

me demande si il y a pas une boucle sur un update, car ca fait beaucoup je trouve

faudra attendre la reponse du support :s

Modifié le 8 décembre 2014 par Gaetan Cambier

[PetitGreg]

Bon bin, j'ai craqué... j'ai bricolé mon /etc/postgresql/postgresql.conf de mon coté.
Je lui ai rajouté :

log_statement = all
log_min_error_statement = error

Pour d'avantage de lisibilité et de sureté, j'ai stoppé tous les packages qui pouvaient utiliser postgreSQL.

Un petit redémarrage du service /usr/syno/etc.defaults/rc.sysv/S20pgsql.sh
J'ai relancé le package Download Station et ça part bien dans les logs (/var/log/postgresql.log).

-> Situation normale :

Quand le GUI est ouvert (ou au premier plan, merci brunobruno69 de l'avoir remarqué), et que les tâches sont toutes inactives, il y a un rafraichissement des tâches affichées toutes les 6 secondes (ce ne sont que des opérations SELECT, donc des lectures dans la base, rien de terrible pour l'I/O parce que ça ne concerne que quelques tâches : celles affichées).

-> Situation anormale :
Quand le GUI est ouvert (ou au premier plan), et qu'il y a des tâches actives, il y a une mise-à-jour (opérations UPDATE, donc là, il y a écriture) de leurs états (les variables suivantes dans le cas de tâches BT : current_size, current_rate, total_peers, connected_peers, total_pieces, downloaded_pieces, available_pieces, upload_rate, total_upload, seeding_elapsed, seeders, leechers). Le soucis cette fois-ci, c'est que ce sont TOUTES les tâches actives présentes qui sont mises-à-jour, et pas seulement celles affichées.

Pour avoir laisser le GUI ouvert à peine 2 secondes (le temps qu'il charge et affiche des données), le retour à un état normal niveau I/O a pris 1min 38. Pendant ce laps de temps, il y a eu 6 opérations UPDATE par tâche !

Il ne reste plus qu'à expliquer tout ça et à envoyer un petit log au support de Synology...

Hors sujet (ou peut-être pas finalement) : j'ai vu passé une opération VACUUM FULL plus tôt. D'après des docs (http://www.postgresql.org/docs/current/static/sql-vacuum.html), pendant ce nettoyage, il a des verrous sur les tables en question, ce qui veut dire que ça ne pose pas de problème pour un SELECT (une simple lecture) mais pas un UPDATE (lecture registre puis écriture).

Modifié le 8 décembre 2014 par PetitGreg

[PetitGreg]

Bon...
Le support de Syno n'arrive à reproduire ce problème (ils ont de la chance !) et me demande de leur donner accès distant à l'intégralité de mon NAS...
...avec une notion très particulière de la sécurité en me demandant d'activer telnet (pas SSH ! telnet !!! Zéro cryptage ! Tout en clair !) et de forwarder le port TCP23 vers mon NAS !
Même leur outil intégré depuis DSM 5.1 pour tester la configuration de sécurité demande à modifier le port du service SSH quand ce dernier est activé.
Et là, ils me demandent de leur ouvrir les portes grandes ouvertes sur le port standard du telnet, ce n'est pas sérieux !

Je ne suis pas chaud pour ça, j'ai refusé mais je leur ai proposé de leur envoyer les données qu'ils souhaiteraient (fichiers de conf, databases, etc...).
Pas de réponse du support depuis.

De mon coté, j'ai totalement recréé mes bases PostgreSQL, le problème est toujours là, donc ça ne venait pas d'éventuelles erreurs de migration des précédentes bases.

[gaetan.cambier]

tu peux leur donner un acces ssh, ils accepteront, mais bon, ca reste avoir un full access a ton nas qui t'embete surement

[PetitGreg]

Je sais que je peux leur donner un accès SSH, c'est que j'aurais fait, mais je n'ai pas envie qu'un tiers vienne sur mon NAS, j'y ai des fichiers personnels/confidentiels et j'ai aussi des applications/services qui dépendent des données présentent dessus, et je n'ai pas envie que le support stoppe des services du NAS ou le redémarre n'importe quand.

[PetitGreg]

Le support m'a conseillé un RESET et une réinstallation de DSM, c'est assez contraignant parce que les fichiers de sauvegarde ne sauvegardent pas grand chose au final, mais Download Station fonctionne de nouveau normalement chez moi.
Les causes du problème resteront inconnues de mon coté. Dommage...

[brunobruno69]

Bien de la chance mois je vais faire avec, peut être sa passera un jours sans convictions.

[brunobruno69]

Toujours avec mon problème et pas envie de faire un reset laborieux pour mon nivaux

chez mois l interface download station lancé le Volume iSCIS monte A 100% et réduit les transfert a la fermeture le Volume iSCIS retombe A 1% en 1 ou 2 minutes