Calcul du md5 de millions de fichiers

Version imprimable

Voir 40 message(s) de cette discussion en une page

12/09/2014, 16h17
benratti

Personnellement, j'utilise plutôt JProfiler (qui est payant, mais tu peux utiliser une licence d'evaluation renouvelable) qui te simplifie l'interpretation des chiffres par rapport à celui de netbeans.

Concernant ton problème, il est problable que ton problème vienne de ta base, où de la manière dont tu l'interroges où que tu y accèdes. Le profiler t'aidera en parti pour cibler le problème, si tu vois que tu as beaucoup de thread en attente de connexion à la base, c'est par exemple que ton pool de connexion est mal configuré (quoi que, est ce que tu fait du multi-thread ?, donc des accès multiple à la base ?)

Pour tes requetes SELECT, est ce que tu as les bon index ? Quel est la volumetrie de ta table principale ? est ce que tu as déjà des millions de lignes ou seulement 135 ?
12/09/2014, 16h43
Sennad

Citation:

Personnellement, j'utilise plutôt JProfiler (qui est payant, mais tu peux utiliser une licence d'evaluation renouvelable) qui te simplifie l'interpretation des chiffres par rapport à celui de netbeans.

Ok je vais essayer de voir, mais c'est sous RedHat :/

Citation:

Concernant ton problème, il est probable que ton problème vienne de ta base, où de la manière dont tu l'interroges où que tu y accèdes. Le profiler t'aidera en parti pour cibler le problème, si tu vois que tu as beaucoup de thread en attente de connexion à la base, c'est par exemple que ton pool de connexion est mal configuré (quoi que, est ce que tu fait du multi-thread ?, donc des accès multiple à la base ?)

Non pas de multi-threading, ça serait peut-être plus rapide, mais j'ai pas assez pratiqué les thread pour mettre ça en place dans une entreprise, j'ai préféré la jouer tranquille quoi :/

Citation:

Pour tes requetes SELECT, est ce que tu as les bon index ? Quel est la volumetrie de ta table principale ? est ce que tu as déjà des millions de lignes ou seulement 135 ?

Euh oui j'ai fait beaucoup d'index..
Et oui il y a presque 2 000 000 d'enregistrements dans la table... C'est ça qui ralentit ? mais ça sera toujours le cas, yaura même plutôt 100 000 000 d'enregistrements.. :/
12/09/2014, 17h26
Sennad

Je comprends pas.. J'suis désespéré... :'( :arf::arf::arf: :help:
12/09/2014, 19h05
tchize_

Citation:

Envoyé par Sennad

Ouais mais je ne vois pas trop comment je peux faire ça.

En "gros"

Code:

select * from hashes where url like "/chemin/vers/ton/dossier/%"

Une fois que t'as reçu le paquet en local (ce qui devrait être rapide), plus qu'à stocker ça dans une hashmap le temps de parcourir le dossier.

Aussi, si, encore une fois, le seul traitement différencié est de savoir si on a eu un ajout / une modification / un rien, on peut s'en sortir sans devoir pomper au préalable la base de données:

Si la base de données a une colonne "firstSeen" remplie en auto avec le timestamp courant.
Si elle a une colonne "lastUpdated" avec la date de dernière mise à jour

Code:

INSERT INTO Tatable(name,path,hash,firstseen) VALUES ('lenom','lepath','lehash',ladate) ON DUPLICATE KEY UPDATE lastUpdated = IF(hash<>'lehash',ladate,lastUpdated)

Que tu peux du coup faire rentrer dans un batch jdbc facilement pusique c'est la même requête pour tout le monde.

Un fois tout scanné, tu peux finalement créer ton fichier de log avec trois requetes simple:

les modifiés:

Code:

select * from Tatable where lastUpdate >= heureDeDebut and firstSeen < heureDeDebut

les nouveaux:

Code:

select * from Tatable where firstSeen >= heureDeDebut

les pas modifiés:

Code:

select * from Tatable where lastUpdate < heureDeDebut

En base de données, il faut éviter de mettre trop de logique du coté du code utilisateur et plutot du coté du serveur, c'est souvent plus performant :)

Aussi, si t'as 50 process qui attaquent la base en parallèle, tu risque d'avoir un sacré goulot d'étranglement sur les transactions entre ces process.
13/09/2014, 10h13
vic

Est-ce que tu peux préciser pour l'écriture de fichiers, tu dis que tu as 50 fichiers qui sont écrits en même temps ? Si c'est le cas et que tu fais un flush() à chaque ligne c'est une horreur pour le systeme de fichiers, tu cumules tout ce qui est lent pour l'écriture.

Il faut 1) toujours toujours utiliser un BufferedWriter qui garde les données en mémoire et les écrit par "paquet" de temps en temps 2) ne pas faire de flush() manuel sauf si tu as une bonne raison.

Donc il faut que tu crées ton BufferedWriter, exemple:

Code:

BufferedWriter writer = new BufferedWriter(new FileWriter(filePath));

Ensuite tu passes ce BufferedWriter à tes fonctions de parcourt des répertoires et tu écris dedans à la place de la méthode WriteInFile. A la fin du processus quand tout a été analysé tu appelles writer.close().

Une remarque tout de même sur la démarche : le MD5 est faible sur le plan cryptographique, ce qui veut dire qu'une personne mal intentionnée peut causer une collision intentionnellement. Je ne sais pas si c'est un problème dans ton application.

Il existe également d'autres algorithmes plus rapides que MD5, ça vaut peut être le coup si ça fait gagner un jour ou 2 de calcul :lol:
15/09/2014, 11h06
Sennad

Salut et merci pour vos réponses !

Merci Tchize, je vais essayer de mettre ça en place.
Seulement j'ai pas trop compris comment tu veux différencier les fichiers modifié / ajouté / supprimé.
Qu'est-ce que "heureDeDebut" ?
Merci encore !

Merci aussi à toi vic pour ta réponse !
J'écrirai bien 50fichiers en même temps, mais seulement 1 par programme, juste que j'exécute 50 fois ce programme chacun sur une machine différente, et ils écrivent tous dans un fichier qui leurs est propre.
Je comprends pas trop pour le flush, il me semblait que c'était un genre de commit pour les fichiers quoi, et que ça vidait ce qui avait en mémoire pour l'écrire. Je ne vois pas trop le problème mais je dois me tromper.

En ce qui concerne le MD5, j'ai testé le md5 et le sha1 sur plusieurs fichier de taille différente, et ça a toujours été le md5 le plus rapide, d'où mon choix, seulement je ne doute pas qu'il y ait plus rapide (je suis preneur !). Même si le hash n'est pas l'élément bloquant dans mon programme, puisque en enlevant les accès BDD / écriture fichier, mon programme est 120 fois plus rapide (et il fait quand même le hash md5).
Donc mon problème de lenteur ne viens pas du md5, même si une légère amélioration à ce niveau-là serrait quand même significative, j'aimerai quand même résoudre ce problème de lenteur..
15/09/2014, 14h23
benratti

Citation:

Envoyé par Sennad

Seulement j'ai pas trop compris comment tu veux différencier les fichiers modifié / ajouté / supprimé.
Qu'est-ce que "heureDeDebut" ?

Il te propose de te baser sur deux choses : la date de création et la date de mise à jour. "heureDeDebut" correspondra à l'heure de début de traitement. Cela te permettra de récupérer à la fin de ton traitement, les entrés (donc fichiers) qui ont été modifiées ou créées lors de ton dernier traitement. Cela te permettra de limiter grandement le nombre de requete réalisée sur la base, cause probable de tes lenteurs.

Citation:

Envoyé par Sennad

J'écrirai bien 50fichiers en même temps, mais seulement 1 par programme, juste que j'exécute 50 fois ce programme chacun sur une machine différente, et ils écrivent tous dans un fichier qui leurs est propre.
Je comprends pas trop pour le flush, il me semblait que c'était un genre de commit pour les fichiers quoi, et que ça vidait ce qui avait en mémoire pour l'écrire. Je ne vois pas trop le problème mais je dois me tromper.

Le flush te permet de réellement écrire dans le fichier, et c'est cela qui est réellement couteux, notamment l'ensemble des accès disques qui en découle. Le faire pour chaque ligne que tu souhaites est couteux, mieux vaut le faire une fois de temps en temps.
De plus si tu fais des accès concurrents, ça peux poser problème ( mais cela ne semble pas être ton cas ).

Citation:

Envoyé par Sennad

En ce qui concerne le MD5, j'ai testé le md5 et le sha1 sur plusieurs fichier de taille différente, et ça a toujours été le md5 le plus rapide, d'où mon choix, seulement je ne doute pas qu'il y ait plus rapide (je suis preneur !). Même si le hash n'est pas l'élément bloquant dans mon programme,
puisque en enlevant les accès BDD / écriture fichier, mon programme est 120 fois plus rapide (et il fait quand même le hash md5).
Donc mon problème de lenteur ne viens pas du md5, même si une légère amélioration à ce niveau-là serrait quand même significative, j'aimerai quand même résoudre ce problème de lenteur..

Pour l'instant, concentre toi sur les problèmes de lenteurs liés à l'accès à la base et aux fichiers...
15/09/2014, 15h29
Sennad

Citation:

Il te propose de te baser sur deux choses : la date de création et la date de mise à jour. "heureDeDebut" correspondra à l'heure de début de traitement. Cela te permettra de récupérer à la fin de ton traitement, les entrés (donc fichiers) qui ont été modifiées ou créées lors de ton dernier traitement. Cela te permettra de limiter grandement le nombre de requête réalisée sur la base, cause probable de tes lenteurs.

Okey mais je comprends toujours pas pourquoi "lastUpdate >= heureDeDebut and firstSeen < heureDeDebut" serait un fichier modifié ?
Ca veut dire (si je ne me trompe pas) : je l'ai mis a jour (c'est a dire ?) après le début de traitement et firstSeen avant le début du traitement. Ça n'a aucun sens pour moi..
De meme pour "firstSeen >= heureDeDebut"
Et "lastUpdate < heureDeDebut" => mis à jour avant le début du traitement ? :weird:
-> "firstSeen" remplie en auto avec le timestamp courant (A quel moment ??)
-> "lastUpdated" la date de dernière mise à jour (Quelle mise à jour ??)
-> "heureDeDebut" correspondra à l'heure de début de traitement. (Quel traitement ??)
J'ai l'impression d'être lourd là, mais vraiment je comprends pas..

Et comment faire pour mettre à jour la signature d'un fichier qui a était modifié ?
Si je fais mes verifs à la fin, pour un fichier modifié je pourrais pas mettre à jour sa signature, je l'ai plus vu que je fais la vérif a la fin..
Je suis un peu perdu là :(

Citation:

Le flush te permet de réellement écrire dans le fichier, et c'est cela qui est réellement couteux, notamment l'ensemble des accès disques qui en découle. Le faire pour chaque ligne que tu souhaites est couteux, mieux vaut le faire une fois de temps en temps.

Okey parfait, mais du coup si j'enlève le flush de la méthode, j'appelle ma méthode plusieurs fois dans mon code, et au bout d'un moment j'appelle une méthode qui prend en paramètre ce writer, et qui fait un flush c’est ça ? Tous les 500 fichiers ça semble raisonnable ? :)

Encore merci beaucoup pour le temps que vous passez sur mon sujet !!
15/09/2014, 16h33
benratti

Citation:

Envoyé par Sennad

Okey mais je comprends toujours pas pourquoi "lastUpdate >= heureDeDebut and firstSeen < heureDeDebut" serait un fichier modifié ?
Ca veut dire (si je ne me trompe pas) : je l'ai mis a jour (c'est a dire ?) après le début de traitement et firstSeen avant le début du traitement. Ça n'a aucun sens pour moi..
De meme pour "firstSeen >= heureDeDebut"
Et "lastUpdate < heureDeDebut"
-> "firstSeen" remplie en auto avec le timestamp courant (A quel moment ??)
-> "lastUpdated" la date de dernière mise à jour (Quelle mise à jour ??)
-> "heureDeDebut" correspondra à l'heure de début de traitement. (Quel traitement ??)
J'ai l'impression d'être lourd là, mais vraiment je comprends pas..

Si tu reprends la requete SQL unique de modification proposée :

Code:

INSERT INTO Tatable(name,path,hash,firstseen) VALUES ('lenom','lepath','lehash',ladate) ON DUPLICATE KEY UPDATE lastUpdated = IF(hash<>'lehash',ladate,lastUpdated)

Celle ci fait plusieurs chose à la fois :
1. Si le fichier n'existe pas dans ta table, elle te l'insert
2. Si ton fichier existe (ON DUPLICATE KEY), il te met à jour la date => peux être faut il aussi mettre à jour le hash, à toi de voir.

Tu dois faire ta requete uniquement si tu as constaté que ton hash n'est plus le même, i.e. que ton fichier a été modifié. Donc si ton fichier est modifié, alors sa date de mise à jour (lastUpdated) aura été mise à jour par ta requete.

"firstSeen" est rempli à l'insertion
"lastUpdated" est rempli à la mise à jour.

Avec ça, si tu notes l'heure de début de traitement et de fin de traitement, tu peux facilement retrouver :
* les entrées qui ont été créés
* les entrees qui ont été modifiés

tchize_ t'a donnée les requetes correspondantes.

Citation:

Envoyé par Sennad

Et comment faire pour mettre à jour la signature d'un fichier qui a était modifié ?
Si je fais mes verifs à la fin, pour un fichier modifié je pourrais pas mettre à jour sa signature, je l'ai plus vu que je fais la vérif a la fin..

Le but est de le faire dans ta requete SQL unique de mise à jour
15/09/2014, 17h16
Sennad

Merci encore énormément !

Je comprends très bien l’intérêt, et ce que l'on cherche à faire.
Ça m'énerve parce que tu te donnes beaucoup de mal pour m'aider, mais j'y arrive pas...

FirstSeen => La date de la toute première fois qu'on trouve le fichier.
LastUpdate => Mit à jour si le fichier existe (modifié ou non)
HeureDeDebut => "Heure de début de traitement" - De quel traitement on parle ?

Et aussi comment adapter la requête SQL unique pour que si le hash est différent, qui soit mit à jour ?
15/09/2014, 21h20
tchize_

Effectivement, j'ai été trop vite et oublié le hash, mais ce n'est pas bien compliqué à mettre:

Code:

INSERT INTO Tatable(name,path,hash,firstseen) VALUES ('lenom','lepath','lehash',ladate) ON DUPLICATE KEY UPDATE lastUpdated = IF(hash<>'lehash',ladate,lastUpdated), hash='lehash'

comme tu trouvera un exemple à la fin de la doc mysql sur on duplicate key
http://dev.mysql.com/doc/refman/5.0/...duplicate.html

Citation:

LastUpdate => Mit à jour si le fichier existe (modifié ou non)

Non dans la requête que j'ai fait, lastUpdate est mis à jour uniquement si le fichier est modifié (cf le IF(<modifié>,<nouvelle date>,<ancienne date>)) dans mas requête. C'est ce qui te permet justement de sortir la liste des modifiés à la fin de ton process.

Citation:

HeureDeDebut => "Heure de début de traitement" - De quel traitement on parle ?

Du début de ton scanne. Je part du principe que ton programme ne sature pas ta base de données en continu et a pour but de se lancer comme un grand à intervalles réguliers.

Tes temps de base de données me semblent quand même suspect. Tu en arrive à combien de requêtes exécutées par secondes dans tes tests actuels?
16/09/2014, 10h42
Sennad

3 pièce(s) jointe(s)

Salut !!
Merci pour ta réponse !

Citation:

Tes temps de base de données me semblent quand même suspect. Tu en arrive à combien de requêtes exécutées par secondes dans tes tests actuels?

Actuellement mon programme tourne sur un gros répertoire, et mySql Workbench, dans l'onglet Dashboard m'indique entre 0 et 1 SELECT / sec :weird: :
Pièce jointe 156309
Pièce jointe 156306
Pièce jointe 156307

Sinon je pense avoir enfin compris ! :rire: :applo:

Citation:

Citation:

HeureDeDebut => "Heure de début de traitement" - De quel traitement on parle ?

Du début de ton scanne. Je pars du principe que ton programme ne sature pas ta base de données en continu et a pour but de se lancer comme un grand à intervalles réguliers.

Mon programme est lancé 1 fois par semaine, je stocke déjà le numéro de la semaine, pour trouver les fichiers supprimé, à la fin du traitement, je récupère tous ceux qui ont un num de semaine inférieur à celui actuel.
Donc fichiers supprimés :arrow: OK
Ensuite nouveaux fichiers :
firstSeen >= heureDeDebut :arrow: OK
Maintenant fichiers modifiés :
"lastUpdate >= heureDeDebut and firstSeen < heureDeDebut"
Pourquoi ne pas récupérer seulement ceux qui ont lastUpdate = semaine actuelle ?

Récap :
:fleche: New files => firstSeen = currentWeek
:fleche: Modified files => lastUpdate = currentWeek
:fleche: Deleted files => currentWeek == getCurrentWeek();
Où currentWeek est la colonne représentant le numéro de la semaine de début de traitement.

Merci encore énormément !
16/09/2014, 11h05
benratti

Peux tu regarder le temps d'execution de ta requete SQL ? J'ai bien l'impression que celle-ci est très lente.
Peux tu également nous montrer les index présents sur ta table ?
16/09/2014, 11h06
Sennad

Salut !

Euh comment je récupère le temps de la requête ?
Pour les index je fais ça dessuite !
16/09/2014, 11h10
Sennad

1 pièce(s) jointe(s)

Pièce jointe 156312
16/09/2014, 11h15
Sennad

Mais je pense que le problème viens de l'installation de mySql..
Je suis sous red hat, et je n’ai pas les droits roots.
J'ai donc installé mon serveur dans un répertoire dans mon /home.
J'ai modifié le my.cnf pour lui donner le root directory du server à savoir /home/mySqlServer/
J’ai réussi à le démarrer, mais j'ai rien fais depuis, il est démarré depuis 3 mois, et a reçu beaucoup de requêtes.
J'ai voulu le redémarrer, sauf que je ne peux même pas l'arrêter. Il me dit qu’il ne trouve pas certains fichiers, fichiers qu’il ne cherche pas dans le répertoire que je lui ai donné "/home/mySqlServer/".
Bref impossible de redémarrer mySql..
Peut-être le problème vient de là ?
16/09/2014, 11h20
Sennad

Le Select a mit une fois 1sec, et une autre fois 2sec.. C'est hyper long omg.. :weird:
C'est ce que me dis NetBeans quoi. Il a fait juste un Select et affiché le résultat. Fini : BUILD SUCCESSFUL (total time: 2 second) et une autre fois sur un autre enregistrement 1sec.
16/09/2014, 11h33
Sennad

1 pièce(s) jointe(s)

Ce qui me fait le plus pensé que le probleme viens de la DB est que le InnoDB Buffer Pool est tout le temps à 100%.. :
Pièce jointe 156313
16/09/2014, 14h19
tchize_

Citation:

Envoyé par Sennad

Actuellement mon programme tourne sur un gros répertoire, et mySql Workbench, dans l'onglet Dashboard m'indique entre 0 et 1 SELECT / sec :weird: :

mouais c'est bizarre. C'est plutot le comportement de ton programme qui m'intéresse. Suffit de faire nombre de requêtes faites par ton programme / (heure de fin- heure de départ) => ca donnera une idée des performance de ta requête. De plus ton workbench te donne une requête / seconde mais te dit que innodb lit comme un porc le disque (>100Mb/s). Tu peux nous montrer comment tu établis ta connection avec la base de données?

Citation:

Envoyé par Sennad

Maintenant fichiers modifiés :
"lastUpdate >= heureDeDebut and firstSeen < heureDeDebut"
Pourquoi ne pas récupérer seulement ceux qui ont lastUpdate = semaine actuelle ?

Parce que ça incluerait les nouveaux fichiers

Citation:

Envoyé par Sennad

Récap :
:fleche: New files => firstSeen = currentWeek
:fleche: Modified files => lastUpdate = currentWeek and firstSeen != currentWeek
:fleche: Deleted files => currentWeek == getCurrentWeek();

Citation:

Envoyé par Sennad

Le Select a mit une fois 1sec, et une autre fois 2sec.. C'est hyper long omg.. :weird:
C'est ce que me dis NetBeans quoi. Il a fait juste un Select et affiché le résultat. Fini : BUILD SUCCESSFUL (total time: 2 second) et une autre fois sur un autre enregistrement 1sec.

Oui, mais attention, ceci inclu le temps pour établir une connection avec le serveur.

Citation:

Tu peux nous montrer comment tu établis ta connection avec la base de données?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 public static final void loadMySQLDriver() {
        try {
            Class.forName(com.mysql.jdbc.Driver.class.getName());
        } catch (Exception e) {
            throw new RuntimeException("Driver failed to load");
        }
    }
 
    public static final Connection getConnection() {
        try {
            return DriverManager.getConnection(Constants.getConnectionString(), Constants.DB_USER, Constants.DB_PASSWORD);
        } catch (SQLException e) {
            System.out.println(e.getSQLState());
            System.out.println(e.getMessage());
        }
        return null;
    }

La methode loadMySqlDriver est appelée une seule fois.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public static final String getConnectionString() {
        String ip = "";
        String port = "";
        String databaseName = "";
        String StringToReturn;
        try (BufferedReader in = new BufferedReader(new FileReader(ConfigurationFile_PATH));) {
            String line;
            while ((line = in.readLine()) != null) {
                if (line.equals("IP SERVER MySQL =")) {
                    line = in.readLine();
                    ip = line;
                }
                if (line.equals("PORT MySQL =")) {
                    line = in.readLine();
                    port = line;
                }
                if (line.equals("DATABASE NAME =")) {
                    line = in.readLine();
                    databaseName = line;
                }
            }
            StringToReturn = CONNECTOR + "://" + ip + ":" + port + "/" + databaseName; //CONNECTOR = jdbc
            return StringToReturn;
        } catch (Exception e) {
            System.out.println("!! Problem getting connection string DB !!");
            e.printStackTrace();
            throw new RuntimeException();
        }
    }

Citation:

Récap :
New files => firstSeen = currentWeek
Modified files => lastUpdate = currentWeek and firstSeen != currentWeek
Deleted files => currentWeek == getCurrentWeek();

Ok parfait ;)

Citation:

Oui, mais attention, ceci inclu le temps pour établir une connection avec le serveur.

Oui effectivement..
Je suis actuellement a environ 2fichiers/secondes.. (J'ai réussi a gagner un peu en augmentant (128Mo -> 2 Go) le "InnoDB buffer pool")

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 20h42.