Synchronisation de dossiers contenant beaucoup de fichiers / Utilisation CPU importante


#1

Bonjour Cozy :slight_smile:

J’ai tenté de vous envoyer des messages via l’application à propos de soucis de performance que j’ai constaté en utilisant Cozy Drive pour ordinateur. Au vu de certains logs (que malheureusement je n’ai pas réussi à retrouver), j’ai l’impression que les messages n’ont pas été envoyés correctement et que vous ne les avez donc pas reçu. Précision importante : je suis auto-hébergé, il est donc possible que cela vienne d’un problème de configuration de mon côté. Bref, je me suis dit qu’il serait tout de même intéressant de poster mes observations ici, même si vous n’aurez pas accès à mes logs.

Ces dernières semaines, j’ai fait un certain nombre de tests afin de mesurer la performance de Cozy Drive. En effet, même si j’ai réussi à synchroniser un bon nombre de “petit” dossiers sans problème (j’ai même été agréablement surpris par la vitesse d’upload :wink: ), j’ai été bloqué par un dossier contenant 28 000 fichiers (des emails). Même après une nuit, le dossier n’était pas synchronisé.

Etonné par cette différence de performance entre les petits dossiers et les gros dossiers, j’ai donc décidé de faire des tests. J’ai chronométré le temps nécessaire pour synchroniser des dossiers de taille variable. J’ai tout rassemblé dans ce CSV :

n_files,size(Mo),time_to_upload(s)
55,192,90
12,79,47
42,276,101
532,301,406
27,207,75
528,152,302
6653,963,4406
3166,300,4085

Je n’ai pas réussi à synchroniser de dossier contenant plus de 7000 fichiers. Ainsi, tout se passe comme s’il y avait une sorte de limite sur le nombre de fichiers, au delà de laquelle la synchronisation est très fortement ralentie. Cela ne semble pas être causé par la taille des fichiers mais bien par leur nombre. Avez-vous déjà constaté ce problème ?

Depuis que j’ai réalisé ces tests, j’ai également un deuxième problème. Cozy Drive consomme 65% en CPU même lorsque tout est à jour. Du coup, je ne peux pas utiliser correctement mon ordinateur quand l’application tourne et je suis obligé de l’arrêter.

Pourtant, même du point de vue des logs, rien n’a l’air de se passer. Je trouve ça vraiment étrange. Je me demande si ça n’est pas dû aux tests que j’ai fait. En effet, j’ai à plusieurs reprises supprimé des dossiers qui était en train d’être synchronisés (parce que cela prenait trop de temps). Peut-être que le fait d’avoir supprimé des dossiers avant qu’ils soient totalement synchronisés a causé ces soucis ?

Voilà :slight_smile: J’ai cru comprendre que vous travaillez beaucoup en ce moment sur des améliorations de l’application et j’espère que ces observations pourront vous être utiles.


#2

Bonsoir @gcoter,

Merci beaucoup d’avoir pris le temps de faire ces tests. Je les ai transmis à l’équipe et ils nous seront utiles le moment venus.

Malheureusement, nous n’avons pas encore pu pour l’instant nous attaquer sérieusement aux soucis de performance, nous nous attachons à améliorer le fonctionnement de l’application dans une foule de « cas limites » où elle ne se comporte pas comme elle le devrait. Nous réfléchissons au Grand Chantier d’Amélioration des Performances, et commençons à préparer le terrain, mais il n’a pas encore commencé.

Nous espérons en finir avec les problèmes de synchronisation d’ici la fin de l’année, et nous attaquer à l’amélioration des performances au début de l’année prochaine.


#3

J’avais oublié de vous répondre sur ce point. Effectivement, nous n’avons rien reçu.
L’envoi des journaux se passe en deux étapes : d’abord, l’application crée une archive avec le dernier journal, et l’envoie sur un de nos serveurs. Puis, elle nous envoie un mail avec votre message. Pour cela elle se connecte à votre serveur et c’est lui qui envoie le mail.

Je viens de regarder sur notre serveur où sont stockés les journaux, et nous les avons bien reçus les 17 et 18 novembre. Nous n’avons par contre pas reçus de message correspondant. peut-être votre serveur n’est-il pas configuré pour envoyer des mails ?


#4

Bonjour @Clochix,

D’accord, je comprends, merci pour votre réponse :slight_smile:


#5

J’ai un serveur Postfix qui tourne mais j’ai également l’impression qu’il n’est pas utilisé par Cozy. C’est la première fois que je mets en place un serveur mail, il est très probable que je ne l’aie pas configuré correctement. J’essaierai de regarder ce qui ne va pas prochainement.


#6

Rebonjour :slight_smile:

J’aurais une autre question par rapport au fonctionnement de Cozy Drive. J’ai essayé de déplacer trois dossiers (3000 fichiers en tout) dans mon dossier Cozy Drive. En regardant les logs, je vois ce message :

{"name":"Cozy Desktop","hostname":"LAPTOP-98QJPBLQ","pid":8860,"component":"ChokidarWatcher","level":20,"msg":"Flushed 3003 events","time":"2018-12-02T15:08:50.018Z","v":0} 

Puis il ne se passe rien. Est-ce normal ? Je me serais attendu à ce que les dossiers se synchronisent avec mon serveur. Par contre, l’utilisation CPU reste élevée tant que l’application tourne. Est-ce un bug de mon côté ou un problème déjà connu ?


#7

Hello @gcoter,

Le message est normal. Par contre, les nouveaux fichiers auraient dû être envoyés sur votre serveur.
Pour savoir si c’est « juste » un souci de performances, ou si l’application rencontre des erreurs, il faudrait regarder les journaux. Vous pouvez tenter un grep '"err"\|"level"=50' ~/.cozy-desktop/logs.txt pour voir si le journal de l’application contient des erreurs.


#8

Hello @Clochix,

Effectivement, j’ai trouvé plusieurs messages d’erreur de ce type :

{"name":"Cozy Desktop","hostname":"LAPTOP-98QJPBLQ","pid":10144,"component":"RemoteCozy","level":50,"err":{"message":"<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.10.3</center>\r\n</body>\r\n</html>\r\n","name":"FetchError","stack":"FetchError: <html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.10.3</center>\r\n</body>\r\n</html>\r\n\n    at handleResponse (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\fetch.js:109:15)\n    at C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\fetch.js:25:29\nFrom previous event:\n    at C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\fetch.js:25:17\n    at runCallback (timers.js:781:20)\n    at tryOnImmediate (timers.js:743:5)\n    at processImmediate [as _immediateCallback] (timers.js:714:5)\nFrom previous event:\n    at cozyFetch (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\fetch.js:7:30)\n    at fetchJSON (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\fetch.js:95:10)\n   at Client.cozyFetchJSON (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\fetch.js:68:10)\n    at Client._fetchJSON [as fetchJSON] (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\node_modules\\cozy-client-js\\dist\\webpack:\\src\\index.js:234:38)\n    at RemoteCozy.fetchFileCorruptions (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\core\\remote\\cozy.js:248:36)\n    at Sync.reuploadContentMismatchFiles (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\core\\sync.js:505:51)\n    at Sync.start (C:\\Users\\Guillaume COTER\\AppData\\Local\\Programs\\CozyDrive\\resources\\app.asar\\core\\sync.js:99:16)\n    at <anonymous>"},"msg":"Cannot get fileCorruptions","time":"2018-11-23T20:19:33.843Z","v":0}

J’ai également cherché dans les logs plus anciens. Apparemment, j’ai ce message depuis au moins le 21 Novembre.


#9

Hello @gcoter,

A priori cette erreur est sans rapport (c’est lié à une fonctionnalité spécifique à notre stockage, qui n’a pas de raison d’être en auto-hébergement. L’erreur 500 retournée par le serveur n’est pas très jolie, et on va améliorer le code pour retourner un truc plus propre, mais normalement ça n’a aucun effet sur la synchronisation.

Je pense que ton appli est toujours en train de calculer les sommes de contrôle des 3000 fichiers que tu as ajoutés (avant de synchroniser un fichier, on calcule une somme de contrôle, qui permet ensuite de savoir s’il a été modifié. C’est cette opération qui consomme beaucoup de ressources).


#10

D’accord, je crois que je vois ce que tu veux dire. Quand je faisais mes tests de performance, je voyais passer des logs avec le message “Checksum complete” si je me souviens bien. Je suppose que cela correspond aux sommes de contrôle dont tu parles.

Mais si l’appli était encore en train de calculer ces sommes de contrôle, est-ce que je ne devrais pas voir des logs de ce genre justement ? Ce que je trouve vraiment bizarre, c’est que je ne vois rien dans les logs alors que pourtant l’appli semble tourner à plein régime.


#11

Hello,

Oui, normalement je crois que le message Checksum complete indique que l’application a calculé la somme de contrôle d’un fichier. Tu devrais en voir dans les journaux.

Pour l’instant, l’application n’écrit rien du tout dans son fichier journal ?


#12

Hello,

J’ai relancé l’application tout en regardant les logs au fur et à mesure (avec un tail -f ~/.cozy-desktop/logs.txt).

Au début, il y a pas mal de messages qui semblent correspondre à l’initialisation de l’application. Si je comprends bien, elle fait une passe sur tous les fichiers pour vérifier s’il y a eu des changements. Ca ne dure pas longtemps (quelques minutes je dirais).

Le dernier log qui s’affiche est :

{"name":"Cozy Desktop","hostname":"LAPTOP-98QJPBLQ","pid":14816,"component":"ChokidarWatcher","level":20,"msg":"Flushed 19197 events","time":"2018-12-05T22:34:51.204Z","v":0}

Puis rien… J’ai attendu une vingtaine de minutes, il n’y a pas eu d’autres logs après celui-là. Par contre, l’application continue à utiliser dans les 60% de CPU malgré tout. Quand je quitte l’application, je reviens à une utilisation normale.

Donc, je confirme que l’application continue à tourner à fond sans écrire de logs.


#13

Bon, c’est connu et en cours d’amélioration. Actuellement le code qui observe le système de fichiers pour détecter des mises à jour n’est vraiment pas optimal. Il consomme beaucoup de ressources juste pour savoir si quelque chose a été modifié.
Nous sommes en train de le ré-écrire entièrement. Ça prend un peu de temps mais la prochaine version devrait être beaucoup moins gourmande.