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).
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. ;)
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).
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. ;)
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).
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. ;)
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.
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.
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.
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).
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
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).
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: https://lists.debian.org/m14jfg$c7b$1@ger.gmane.org
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).
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
Le 09/10/2014 02:05, Francois Lafont a écrit :
>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.
Il suffit de retirer la màj de cron et le tour est joué.
Le 09/10/2014 02:05, Francois Lafont a écrit :
>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.
Il suffit de retirer la màj de cron et le tour est joué.
Le 09/10/2014 02:05, Francois Lafont a écrit :
>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.
Il suffit de retirer la màj de cron et le tour est joué.
[...]Il suffit de retirer la màj de cron et le tour est joué.
Retirer la mise-à-jour de cron rend l'intérêt de locate plutôt limité. L'idée
lancée par Belaïd était justement de profiter du fait que la base locate est à
jour et que donc la réponse sera rapide. Si la base n'est plus à jour, la
réponse ne sera plus rapide et donc la solution perd tout son intérêt.
[...]
Il suffit de retirer la màj de cron et le tour est joué.
Retirer la mise-à-jour de cron rend l'intérêt de locate plutôt limité. L'idée
lancée par Belaïd était justement de profiter du fait que la base locate est à
jour et que donc la réponse sera rapide. Si la base n'est plus à jour, la
réponse ne sera plus rapide et donc la solution perd tout son intérêt.
[...]Il suffit de retirer la màj de cron et le tour est joué.
Retirer la mise-à-jour de cron rend l'intérêt de locate plutôt limité. L'idée
lancée par Belaïd était justement de profiter du fait que la base locate est à
jour et que donc la réponse sera rapide. Si la base n'est plus à jour, la
réponse ne sera plus rapide et donc la solution perd tout son intérêt.
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.
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
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.
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: https://lists.debian.org/m14jfg$c7b$1@ger.gmane.org
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.
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
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: 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: https://lists.debian.org/54364FAC.1090005@freeatome.com
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
--
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/
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.
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.
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.
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.
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.
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.
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 serve ur
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 re pré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).
Je pense que le plus économique est le find comme déjà ind iqué
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 (po ur 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 ser veur
durant son exécution mais plus l'exécution sera longue. à l'inverse,
moins la commande sera « gentille », plus elle perturbera le se rveur
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
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 serve ur
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 re pré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).
Je pense que le plus économique est le find comme déjà ind iqué
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 (po ur 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 ser veur
durant son exécution mais plus l'exécution sera longue. à l'inverse,
moins la commande sera « gentille », plus elle perturbera le se rveur
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: https://lists.debian.org/m14jfg$c7b$1@ger.gmane.org
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 serve ur
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 re pré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).
Je pense que le plus économique est le find comme déjà ind iqué
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 (po ur 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 ser veur
durant son exécution mais plus l'exécution sera longue. à l'inverse,
moins la commande sera « gentille », plus elle perturbera le se rveur
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
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/m14jfg$c7b$
