[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: parcours de millions de fichiers



Le 09/10/2014 10:36, Philippe Gras a écrit :

Le 9 oct. 14 à 02:05, Francois Lafont a écrit :

Bonsoir,

Le 09/10/2014 00:03, Belaïd a écrit :

Pourquoi ne pas utiliser la base de donnée de la commande locate ?

J'espère pour le PO que locate n'est pas installé sur son serveur
de production car il n'y a pas de miracle, si cet outil va très
vite c'est parce qu'il met à jour régulièrement un base représentant
l'ensemble de l'arborescence de fichiers. Sur un serveur avec autant
de fichiers que le PO, ça peut avoir des conséquences très mauvaises
au niveau perf (pendant que locate scanne l'arborescence, tout est
ralenti).

Vous êtes sûr de ça ? Quand j'effectue des mises à jour ou que je mets un
nouveau fichier sur le serveur, je dois faire ‘updatedb' pour que locate les
prenne en compte.

oui, mais si c'est le updatedb est dans le cron, tu attends le lendemain, tu auras ton fichier dans la base.

pour mes serveurs, j'ai désactivé ce genre de chose. locate est bien pour un usage à petite échelle: trouver ses photos ou vidéos de vacances, c'est très pratique. mais sur une baie SAN, c'est interdit. j'ai vu des admins se faire taper sur les doigts pour avoir lancé un ls -R sur un serveur de prod à 9h du matin. vu le prix du giga sur un baie SAN en fibre optique ... vaut mieux éviter de la stressé de cette manière tous les jours.

de toute façon, ce genre de demande est rare. j'ai planifié le truc sur une semaine entière. aujourd'hui je vais faire sur un autre lot de 7millions à partir de 12h00, avec ionice, comme le conseillent des membres de la liste. c'est une bonne idée, car on a aussi des bases Oracle à la maison. pour ceux qui connaissent, une base oracle en data warehouse ca bouffe bien les IO comme de petits pains. il faut bien savoir les gérer.



Je pense que le plus économique est le find comme déjà indiqué
car il n'y a qu'un seul processus. Ensuite, si le but recherché
est de perturber le serveur le moins possible, alors effectivement
il ne faut pas hésiter à utiliser *simultanément* nice (pour que le
processus soit gentil au niveau CPU) et ionice (pour qu'il soit
gentil au niveau I/O). Évidemment, ça va allonger le temps d'exécution
de la commande, pas de miracle.
Plus la commande sera « gentille » moins elle perturbera le serveur
durant son exécution mais plus l'exécution sera longue. À l'inverse,
moins la commande sera « gentille », plus elle perturbera le serveur
durant son exécution mais plus l'exécution sera rapide. Perso, si
rien ne presse, je préfère lancer une commande « gentille » en tâche
de fond sur un serveur de prod quitte à attendre le lendemain pour
avoir le résultat final. ;)

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: [🔎] m14jfg$c7b$1@ger.gmane.org">https://lists.debian.org/[🔎] m14jfg$c7b$1@ger.gmane.org




Reply to: