Discussion :

[Bouga74]

Bonjour à tous,

Je dois souvent mettre à jour une date qui se trouve au début de nombreux fichiers Xml très volumineux.

Actuellement j'utilise la commande suivante qui fonctionne très bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sed -i "s/<day>20160202<\/day>/<day>20160203<\/day>/g" ./File-*

Cependant, vu la taille et le nombre de mes fichiers, cela peut parfois me prendre un temps considérable (1 minute par fichier de 1.5GB, jusqu'à 8-10 minutes pour des fichiers de 20GB).

Sachant que ce texte recherché se trouve uniquement en en-tête du fichier (dans les 10 premières lignes), est-ce qu'il y a une commande qui me permette de gagner du temps ?

Avec la commande que j'utilise, il recopie tout le contenu du fichier dans un fichier temporaire et cette étape me fait perdre énormément de temps.

Merci d'avance pour votre aide !

[disedorgue]

Bonjour,

Il n'y a pas trop de solution car tous les outils sont un peu obliger de passer par des fichiers tampon.
Après, j'aurai du mal à te plaindre: Avoir des fichiers xml de 20 Go, pour moi, c'est une aberration.

Sinon, tu peux éventuellement réduire ton temps globale en découpant ton simple sed -i '...' file-* en plusieurs process.
Autant de process que tu as de cpu sans dépasser disons les 15 process en // car de toute façon, tu seras limité par des attentes I/O.

[BufferBob]

salut,

comme dit disedorgue y'a assez peu de possibilités, j'ai déjà vu faire à coups de dd mais je ne me souviens plus de comment c'était gaulé pour être honnête

sinon peut-être via ed avec un truc du genre (ça marche aussi avec vim et cie.) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
ed -s fichier <<EOF
,s/<day>20160202<\/day>/<day>20160203<\/day>/g
wq
EOF

le seul inconvénient c'est qu'inévitablement ça va pomper toute la mémoire pour ouvrir/lire le fichier...

Edit: un truc comme ça devrait fonctionner, notamment parceque dans ton cas la chaine à remplacer à la même taille que la chaine de remplacement (en fait y'a guère qu'un chiffre qui change) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
str_from='<day>20160202</day>'
str_to='<day>20160203</day>'
grep -b -o -F "${str_from}" fichier | cut -d':' -f1 | while read offset; do echo -ne "${str_to}" | dd of=fichier conv=notrunc bs=1 seek=${offset} 2>/dev/null; done

à voir si ça accroit vraiment les perfs ou si ça génère plus d'io que ce que ça aide...

[jlliagre]

La taille de la chaîne de remplacement étant égale à la taille de la chaîne à remplacer, un fichier intermédiaire est techniquement superflu. Malheureusement, les utilitaires standard vont lire la totalité du fichier puis en le réécrire aussi en totalité en passant par ce fichier intermédiaire ou par son image en mémoire.

Lire puis écrire tout le fichier est extrêmement pénalisant puisque seuls quelques secteurs du disque sont concernés dans ton cas.

Voici une méthode avec `dd` qui fonctionne si la chaîne à remplacer se trouve dans les 4096 premiers octets du fichier (à augmenter donc si ce n'est pas le cas):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
dd if=File-001.xml of=tmp.xml bs=4096 count=1
sed -i "s/<day>20160202<\/day>/<day>20160203<\/day>/g" tmp.xml 
dd if=tmp.xml of=File-001.xml seek=0 conv=notrunc

[disedorgue]

Pas mal la solution avec "dd" , ça fonctionne aussi sur un partage nfs ou samba ?

[jlliagre]

Sûrement, sinon ce serait un gros bug de l'implémentation de NFS ou CIFS ...

[Flodelarab]

Bonjour

Si l'entête prend les 20 premières lignes, est-ce que ceci va plus vite ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sed -i "1,20s/<day>20160202<\/day>/<day>20160203<\/day>/g" ./File-*

Celui lui évitera de chercher une correspondance dans le million de lignes qui suit.

[jlliagre]

Seule la recherche dans le reste du fichier est évitée, pas la lecture et la réécriture de la totalité du fichier qui est ce qui prends certainement le plus de temps.

[Flodelarab]

Si on en est là, ça vaut le coup de faire un patch en C++ qui ne modifiera qu'une séquence d'octets préalablement repérée. Non ?

[Bouga74]

Merci à tous pour votre aide et vos idées

La taille de la chaîne de remplacement étant égale à la taille de la chaîne à remplacer, un fichier intermédiaire est techniquement superflu. Malheureusement, les utilitaires standard vont lire la totalité du fichier puis en le réécrire aussi en totalité en passant par ce fichier intermédiaire ou par son image en mémoire.

Lire puis écrire tout le fichier est extrêmement pénalisant puisque seuls quelques secteurs du disque sont concernés dans ton cas.

Voici une méthode avec `dd` qui fonctionne si la chaîne à remplacer se trouve dans les 4096 premiers octets du fichier (à augmenter donc si ce n'est pas le cas):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
dd if=File-001.xml of=tmp.xml bs=4096 count=1
sed -i "s/<day>20160202<\/day>/<day>20160203<\/day>/g" tmp.xml 
dd if=tmp.xml of=File-001.xml seek=0 conv=notrunc

==> ca marche niquel, même pas le temps de cliquer que mon fichier est déjà à jour !

Bonjour

Si l'entête prend les 20 premières lignes, est-ce que ceci va plus vite ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sed -i "1,20s/<day>20160202<\/day>/<day>20160203<\/day>/g" ./File-*

Celui lui évitera de chercher une correspondance dans le million de lignes qui suit.

==> Ca semble allez un peu plus vite effectivement, genre 40secondes au lieu de 1 minute (même si j'ai testé très vite)

Bonjour,

Il n'y a pas trop de solution car tous les outils sont un peu obliger de passer par des fichiers tampon.
Après, j'aurai du mal à te plaindre: Avoir des fichiers xml de 20 Go, pour moi, c'est une aberration.

Sinon, tu peux éventuellement réduire ton temps globale en découpant ton simple sed -i '...' file-* en plusieurs process.
Autant de process que tu as de cpu sans dépasser disons les 15 process en // car de toute façon, tu seras limité par des attentes I/O.

==> Pas ma faute pour les volumes des fichiers xml, on envoi des données dans une application de gouvernance et le transfert se fait en XML. Actuellement nous n'avons pas d'autre alternative.

Je dois encore tester la solution de BufferBob


Merci à tous !

[zipe31]

Salut,

Voici une méthode avec `dd` qui fonctionne si la chaîne à remplacer se trouve dans les 4096 premiers octets du fichier (à augmenter donc si ce n'est pas le cas):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
dd if=File-001.xml of=tmp.xml bs=4096 count=1
sed -i "s/<day>20160202<\/day>/<day>20160203<\/day>/g" tmp.xml 
dd if=tmp.xml of=File-001.xml seek=0 conv=notrunc

dd if=File-001.xml bs=4096 count=1 | sed 's/<day>20160202<\/day>/<day>20160203<\/day>/' | dd of=File-001.xml seek=0 conv=notrunc devrait le faire aussi, non ?

[BufferBob]

Je dois encore tester la solution de BufferBob

la solution que j'ai proposé à base de dd est intéressante dans le sens où elle est "tout automatique", mais elle a comme inconvénient de faire autant de dd successifs et donc autant d'ouvertures/fermetures du fichier qu'il y a d'occurrences recherchées

si tu sais avec certitude identifier une plage d'octets dans le fichier pour réduire le traitement la solution de jilliagre ou de zipe31 (ça revient au même modulo le oneliner) est à mon avis la plus intéressante

pour l’anecdote ma solution repose sur grep et les options -b, -o et -F

• -b demande à grep d'afficher l'offset dans le fichier de la correspondance trouvée, juste ce dont à besoin dd
• -o permet de ne rater aucune occurrence (s'il y en a plusieurs sur la même ligne)
• -F permet une recherche en fixed string, option souvent oubliée, mais qui dans un fichier de 20G fait probablement la différence avec le traitement par défaut de grep qui cherche à matcher une expression régulière (fût-elle basique)

Si on en est là, ça vaut le coup de faire un patch en C++ qui ne modifiera qu'une séquence d'octets préalablement repérée. Non ?

ouai, je suis assez d'accord, à ce stade j'aurai déjà sorti Perl ou C

[jlliagre]

Si on en est là, ça vaut le coup de faire un patch en C++ qui ne modifiera qu'une séquence d'octets préalablement repérée. Non ?

Pourquoi pas, mais le patch serait en C comme GNU sed, pas en C++. Il faudrait aussi probablement rajouter une option pour activer l'optimisation quand elle est possible.

[zipe31]

la solution de jilliagre ou de zipe31 (ça revient au même modulo le oneliner) est à mon avis la plus intéressante

À part qu'on saute la création du fichier temporaire, ce qui devrait réduire le temps un tant soit peu au passage

[jlliagre]

dd if=File-001.xml bs=4096 count=1 | sed 's/<day>20160202<\/day>/<day>20160203<\/day>/' | dd of=File-001.xml seek=0 conv=notrunc devrait le faire aussi, non ?

Oui ! On gagne quelque microsecondes ;-)

[jlliagre]

la solution que j'ai proposé à base de dd est intéressante dans le sens où elle est "tout automatique", mais elle a comme inconvénient de faire autant de dd successifs et donc autant d'ouvertures/fermetures du fichier qu'il y a d'occurrences recherchées

En s'appuyant sur le problème posé dans ce fil où l'on connait l'emplacement approximatif des chaînes à remplacer, il n'y a qu'une seule ouverture/fermeture par fichier quelles que soient le nombre d'occurrences.

[BufferBob]

Pourquoi pas, mais le patch serait en C comme GNU sed, pas en C++

ça importe pas vraiment, on pourrait tout à fait le faire en C++, d'ailleurs un code purement C reste valide en C++

En s'appuyant sur le problème posé dans ce fil où l'on connait l'emplacement approximatif des chaînes à remplacer, il n'y a qu'une seule ouverture/fermeture par fichier quelles que soient le nombre d'occurrences.

dans le cas où on créerait un bout de code en C ou C++ pour patcher le fichier oui, pas dans la méthode que j'utilise plus haut qui chaine plusieurs dd, plusieurs invocations, plusieurs open/close

[jlliagre]

ça importe pas vraiment, on pourrait tout à fait le faire en C++, d'ailleurs un code purement C reste valide en C++

Essaye de proposer un patch écrit en C++ à la FSF pour GNU sed, tu verras comment tu sera reçu ...

dans le cas où on créerait un bout de code en C ou C++ pour patcher le fichier oui, pas dans la méthode que j'utilise plus haut qui chaine plusieurs dd, plusieurs invocations, plusieurs open/close

Les ouvertures et fermetures de fichier ont très peu d'importance dans l'optimisation dont on discute ici, ce qui compte, c'est de diminuer les lectures et les écritures de blocs au strict nécessaire.

Edit: Je viens seulement de voir le code dont tu parlais et que tu as ajouté à ton post #3. Effectivement, ce n'est pas optimisé car tu lis tout le fichier et réécris plusieurs fois les mêmes blocs. C'est même pire que ça en a l'air car écrire moins que la taille d'un secteur impose une lecture supplémentaire au système d'exploitation.

[disedorgue]

Voici un équivalent en perl:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ perl -e '$recsize=shift; while($recfile=shift){open FH, "+<$recfile" ; $n = read FH,$data,$recsize ; $data =~ s/<day>20160202<\/day>/<day>20160203<\/day>/ ; seek FH, -$n ,1;print FH $data; close FH;}' 4096 file-*

[BufferBob]

proposer un patch écrit en C++ à la FSF pour GNU sed

ouai c'est pas faux, du coup on pourrait se contenter de patcher juste le fichier de données finalement, et laisser GNU sed où il est, c'est pas bête...

Les ouvertures et fermetures de fichier ont très peu d'importance dans l'optimisation dont on discute ici

ça dépend complètement du nombre de substitutions à effectuer, si on considère un fichier de 20G avec 1 seule substitution à effectuer, ma méthode revient exactement au même que la tienne, c'est à dire 1 open, 1 seek, 1 write, 1 close

en revanche si on a 100.000 substitutions a effectuer, on pourrait même imaginer qu'elles sont complètement adjacentes et que substituer 100000 fois un groupe d'octets (la chaine recherchée) ou substituer 1 fois 100000 groupes d'octets revient à écrire la même quantité de donnée sur le disque, pourtant la première solution serait bien plus lente, simplement à cause de la multiplication des appels à open,seek,write et close, des aller-retours entre l'espace utilisateur et l'espace noyau incessants

maintenant si on considère quelque chose de moins aberrant, et possiblement plus proche de la réalité, à savoir un fichier de 20G avec admettons 200 substitutions a effectuer ("<day>20160202</day>" fait 19 octets, dans 4096 octets on peut en placer à peine plus de 200, donc on est dans un cas encore extrême)

• soit on découpe soigneusement un bloc de 4096 octets qui contient les 200 occurrences, c'est très rapide
• soit on passe par un fichier temporaire comme avec sed -i, c'est très lent
• soit on effectue 200 fois à la suite les appels open, seek, write, close, et c'est un peu plus lent que la première solution, mais ça reste tout de même extrêmement rapide par rapport à la deuxième, pour ainsi dire on ne doit pas excéder une ou deux paires de secondes dans le pire des cas, donc il faut tout de même relativiser

un truc simple sinon, tu as déjà essayé de coder une fonction de journalisation dans un programme qui déroule très vite ? l'erreur classique est de mettre open et close dans la fonction, ce qui plombe systématiquement les perfs, la solution adaptée consiste à garder le fichier ouvert et à ne le fermer qu'à la fin du programme, c'est donc que les ouvertures/fermetures de fichier ne sont pas sans conséquence, loin de là

Effectivement, ce n'est pas optimisé car tu lis tout le fichier

tu parles du grep j'imagine, clairement ça n'est pas optimum, mais on s'en fout la lecture ne prend pas tant de temps que ça, c'est de réécrire tout le fichier dans le cadre d'un fichier temporaire qui est consommateur

et réécris plusieurs fois les mêmes blocs.

euh... non.

C'est même pire que ça en a l'air car écrire moins que la taille d'un secteur impose une lecture supplémentaire au système d'exploitation.

je crois que tu te mélanges entre les blocs virtuels qu'on paramètre à dd et les secteurs physiques du disque, dont on a absolument pas connaissance
les blocs définis par bs= et count= sont ni plus ni moins que l'équivalent des paramètres size et nmemb de la fonction fread(3)