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

Re: parcours de millions de fichiers




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.

OK. Merci pour l'info. Je vais regarder à quelle heure s'effectue cette tâche cron. Si c'est pendant la journée, je la désactiverai aussi ! Je trouve locate bien pratique, mais je ne l'utilise pas pour faire des requêtes avec
des millions de résultats.


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



--
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: [🔎] 54364FAC.1090005@freeatome.com">https://lists.debian.org/[🔎] 54364FAC.1090005@freeatome.com



Reply to: