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.

Question : Et tu as bien laissé "0" (zéro, sans guillemets) comme "Taux de téléchargement maximal par tâche" dans Download Station -> Paramètres -> NZB ? Normalement, "Volume/iSCSI" devrait être entre 2 et 5% globalement pendant des téléchargements, quelque soit le nombre de tâches actives, en dehors des opérations de vérifications de conformité des fichiers (PAR/PAR2) et des décompressions automatiques. Le bug que j'ai chez moi bouffe 8 à 10 % par tâche active (!), ce qui peut rapidement saturer "Volume/iSCSI". Le bug ne se manifeste que quand l'interface de Download Station est affiché, les services en tâche de fond liées ne posent pas de problème. Si j'ouvre Download Station, les débits affichés n'ont pas grand chose de cohérent par rapport à ce qui est affiché sur le moniteur de ressources. La saturation de "Volume/iSCSI" fait aussi chuté les débits effectifs. Tant que je ne ferme pas le GUI de Download Station, "Volume/iSCSI" est à 90-99% et les débits deviennent ridiculement petits. Une fois fermer, ça revient à la normale après quelques temps. Si tu veux que Synology soit au courant de ton problème, envois leur un rapport à : https://myds.synology.com/support/support_form.php?lang=enu sinon ça ne va se résoudre tout seul à une prochaine mise-à-jour du package. Ici, c'est un forum d'entre-aide, principalement entre utilisateurs, les éventuels représentants officiels de la marque ne doivent y passer très souvent... Idem pour le forum officiel en langue anglaise ( http://forum.synology.com/enu/viewforum.php?f=10 ). Mais si tu vois 700 KB/s dans Dowload Station, 1400 KB/s dans le moniteur de ressources et que tu es sûr que tu n'as que tes téléchargements qui pompent, ne tient pas compte de ce qu'affiche Download Station. Depuis plusieurs versions, l'interface de Download Station marche très mal, mais pas les daemons associés. Autre question : as-tu essayer de télécharger depuis ton ordinateur avec le même compte sur le même serveur Usenet, et la même configuration serveur (port, cryptage, etc...), pour vérifier que les débits ne sont pas bridés de l'autre coté ?

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.

Bonjour xendery, depuis le moniteur de ressources, et quand l'interface de Download Station est affichée, comment se comporte la ressource "Volume/iSCSI" ? Si "Volume/iSCSI" est à un niveau très important à ce moment là, il y a un bug avec l'interface de Download Station. Tout revient à la normale (débit et Volume/iSCSI) lorsque l'interface de Download Station est fermé (après un certain temps, ça dépend du nombre de tâches actives dans Download Station). Si c'est bien ton cas, je te conseille de faire un bug report (via cette page : https://myds.synology.com/support/support_form.php?lang=enu ) pour remonter ce problème. Cordialement.

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).

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.

@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).

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.

@scoobydoos Download Station, c'est un package de Synology qui permet de télécharger directement depuis le NAS, donc on risque vite d'être hors sujet ici. Si tu as des problèmes de débit lorsque l'interface graphique de Download Station est ouverte, alors tu es bien au bon endroit, c'est un bug qui semble impacter plusieurs personnes à présent (j'en fait aussi partie) sinon il faudra te tourner vers cette partie du forum : http://www.nas-forum.com/forum/forum/78-winmacnfs/ C'est hors-sujet, mais je vais essayer de t'aider un peu. Dans Panneau de conf -> Services de fichiers -> Service de fichiers Windows, tu dis que tout est activé. "Activer le grand MTU" aussi ? Et quoi d'autres ? Dans les paramètres avancés ? Il n'est pas nécessaire d'activer le journal des transferts. Passes-tu par une connexion filaire ou wifi ? Essayes en décochant "Activer le grand MTU" si c'était activé, et si ça ne marche toujours pas, décoches "Activer SMB2". A défaut, c'est moins rapide (sur le papier, parce que tout est relatif, sur mon PC sous Windows 7 j'arrive quand même à 700-800 Mbps sur un lien 1 Gbps avec mon DS1812+ en RAID6, et j'ai les mêmes performances depuis mon Mac avec AFP), mais le débit devrait être plus constant. Le SMB2, ça semble vraiment intéressant quand on transfert plusieurs fichiers en même temps. Si on reste sur du transfert séquentiel, le SMB tout court est encore très honnête en débit. A tester, donc. Cordialement.

Bonjour à tous, Même constat que miltechbv de mon coté, ça plombe les performances de l'ensemble lorsque l'interface graphique liée au package Download Station est sollicitée (ça le fait aussi quand on utilise l'application Download Station sur iOS ou Android). J'ai déjà contacté Synology à ce sujet. @scoobydoos ça te le fait depuis quand ? Depuis la mise à jour 5.1 de DSM ? Depuis la 3.5 de Download Station ? Qu'est-ce qui te fait penser que c'est lié à Download Station (c'est la branche "Download Station" du forum içi) ? As-tu activé SMB2 ou non (panneau de conf -> service de fichiers) ? As-tu essayé avec d'autres protocoles de transfert, comme FTP, SFTP ou NFS (panneau de conf -> service de fichiers) ? Est-ce que ça arrive aussi quand tu fais une copie en interne, du NAS vers le NAS, depuis l'interface de DSM ? Est-ce que ton NAS est déclaré comme "sain" et son volume comme "normal" (gestionnaire de stockage) ? Si le problème est récent, as-tu installé ou mis-à-jour un anti-virus/pare-feu ? Une grosse mise-à-jour de Windows (type service pack) ? Cordialement.

Bonjour à tous, pour T411, sur la 1ère page du site, il y a souvent des infos. Ces derniers temps, ils ont eu des gros problèmes de trackers (et plus récemment de base de données aussi...). Je vous invite donc à bien lire les informations diffusées sur leur site et à consulter cette page : http://irc.t411.me/ip/index.php qui regroupe synthétiquement le bon fonctionnement, ou non, de leurs services (dont le tracker). Cordialement.

Bonjour à tous, Entre temps, T411 est revenu au port 56969... Donc plus besoin de passer sur le port 8880 (qu'ils ont fermé depuis). Sinon pour "changer" le port du tracker dans cette migration, j'ai ajouté le nouveau tracker et supprimé l'ancien (j'ai du recommencer quelques jours plus tard, le 8880 n'était plus d'actualité !), dans l'onglet "Tracker" de chaque tâche (c'est long !), on ne peut pas modifier l'URL du tracker dans Donwload Station (ça doit pouvoir se faire via des moyens détournés, en ligne de commande, mais je n'avais pas envie de trop me prendre la tête, au risque de tout bousiller...). Petite astuce pour savoir si tout marche correctement chez T411 : l'état de leurs services, où on peut voir si le tracker est toujours en ligne : http://irc.t411.me/ip/index.php ça peut éviter de se demander s'il y a quelque chose qui cloche chez soi... Cordialement.

Bonjour lourson6, Lors de la mise-à-jour 3.4 vers 3.5 de Download Station, mon mot de passe pour les nzb a sauté, c'est peut-être ça. D'autres personnes sur le forum ont aussi des problèmes avec des serveurs usenet où les certificats SSL sont auto-signés (moi, je suis chez Eweka et je n'ai pas eu ce problème). Donc, juste pour tester, tu peux essayer un connexion classique sans SSL sur le port 119. Sinon, il faut aussi regarder ce que Download Station raconte dans l'onglet "Journal" de tes tâches NZB pour avoir quelques détails de ce qui se passe. Je ne suis pas sûr qu'utiliser le planificateur de tâches système (cron) pour lancer des tâches différées dans Download Station soit une très bonne idée. Il vaut mieux utiliser la planification intégrée avec le calendrier. Mais si tu t'en sens capable, il doit être possible d'écrire des scripts bash pour quand même les intégrer dans cron, mais il faut mettre les mains dans le cambouis et ça n'aura rien de très user friendly... Libre à toi aussi d'essayer et de tester d'autres packages que Download Station, il en existe d'autres sur https://synocommunity.com/packages , et de nous faire part de ton expérience là-dessus. (pour "installer" SynoCommunity dans le "Centre de paquets" : https://synocommunity.com/#easy-install , il peut être nécessaire d'y changer le "niveau de confiance" dans les paramètres de "Synologi Inc." à "Synology Inc. et les éditeurs de confiance" si ce n'est pas déjà fait).

Bonjour highelf, pourrais-tu développer un peu ta question ? J'avoue ne pas très bien la comprendre... Les fichiers temporaires sont normalement effacés une fois la tâche terminée selon les critères que l'on fixe dans les paramètres généraux de Download Station ou dans les propriétés propres à chaque tâche. De mémoire, par défaut, les paramètres généraux des transferts BT pour qu'une tâche soit terminée sont que le ratio soit 100% (1:1, tu donnes autant que tu reçois), sans aucune limite de temps une fois le download terminé. Une fois, le download terminé, les fichiers téléchargés seront copiés à l'endroit défini précédemment, les fichiers temporaires resteront présents sur le NAS jusqu'à ce que la tâche soit terminée. Une fois, la ratio atteint, les fichiers temporaires seront effacés, et la tâche sera déclarée terminée. C'est globalement logique que des fichiers temporaires soient toujours présents quand on continue à partager des fichiers, car si on modifiait les fichiers finaux pendant ce temps, il y aurait un problème... Ensuite, quand on définie "durée de partage atteint" sur "définitivement" au lieu de "ignorer" (donc la tâche ne s'arrêtera jamais, le seeding continue définitivement), les fichiers temporaires seront supprimés, Download Station prendra les fichiers définitifs comme référence, mais si on les modifie, il re-téléchargera la différence par rapport au torrent d'origine. Sinon, pour effacer les tâches terminées dans Download Station (donc qui ont bien atteint les critères que l'on a défini auparavant, tâches marquées par la présence d'une symbole "check" vert), il y a une petite icône avec un balai, dans la barre supérieure, pour faire le ménage. Cordialement.

Bonjour BruNoMore, chez moi, avec la dernière mise-à-jour, il y a un problème avec l'interface graphique utilisateur (GUI) de Download Station. Si on a des tâches actives (téléchargement et/ou partage), ce problème rend l'interface très lente et dégrade fortement les débits. Tu es peut-être dans ce cas aussi. Ouvre le "moniteur de ressources". Si "Volume/iSCSI" est à un niveau très élevé quand le GUI de Download Station est ouvert depuis l'interface de DSM (ou quand l'application iOS/Android Download Station est utilisée), et qu'après l'avoir fermé il revient à un niveau plus normal après 15 à 120 secondes (selon le nombre de tâches actives), c'est que tu es aussi impacté par ce problème. Ce problème n'affecte les performances de transferts que quand le GUI est ouvert. GUI fermé, les services de Download Station sont normaux, on peut donc voir que ça télécharge correctement depuis le "moniteur de ressources" (ou depuis son widget). Cordialement.

Bonjour crashray, As-tu eu un problème avec tes disques ? Est-ce que le système est considéré comme sain ? avec un volume considéré comme normal ? (on voit tout ça dans le gestionnaire de stockage) Cordialement.

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.

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.