[ Précédent :: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 :: Suivant ]
top ?
Je voudrais écrire un script permettant de relever toutes les X secondes les valeurs de charge de la CPU ainsi que la consommation mémoire.
ça ressemble à top. Mais si tu veux vraiment le réécrire => man proc
Puis-je m'inspirer d'un script qui a déjà été écrit?
oui c'est même recommandé
[ Répondre ]
il faut chercher un peu sur le net
une rapide recherche google m'a donné (premier lien):
http://fy.chalmers.se/~appro/linux/DVD+RW/#growisofs(...)
qui nous apprend comment graver une image iso:
growisofs -Z /dev/scd0=image.iso
toute la complexité réside dans la détermination du périphérique
scsi associé à ton graveur usb.
vu le dmesg, je tenterais /dev/sg2 en lieu et place de /dev/scd0
[ Répondre ]
problème dans l'autre sens
Une meilleure approche serait de migrer la base au possible vers un vrai sgbd comme postgresql et de refaire la base sous access de façon à ce qu'elle attaque les tables postgres par liaison via odbc.
Je n'avais pas eu trop de surprise et même qu' access gagnait en performance, même en comparant avec une base locale.
[ Répondre ]
export
mais bon je pense que tu devrais t'y prendre autrement
déjà le
cat fichier | grep machin
on peut éviter un sous process par
grep machin fichier
mais je taperais un ptit coup de perl pour éviter le gloubiboulga...
#!/usr/bin/perl -w
# script: remptruc.pl
while(<>){
chomp;
s/truc//;
print "$_\n";
}
usage: remptruc.pl fichier
[ Répondre ]
Re: Tout simple
c'est surement peu plus propre de le faire au niveau SQL,
pas sûr. car ta fonction LEFT va être appelée autant de fois qu'il y aura
de tuples dans la réponse.
Donc, suivant les cas il faudra mieux charger le serveur web tantôt le serveur de bdd.
Si les 2 sont sur la même machine, il faut faire des essais de performance.
Sous grosse charge, je créerais une table auxiliaire stockant ce résumé pour éviter de l'extraire à chaque fois. (on perd en place disque
mais le disque est mons cher que le cycle)
[ Répondre ]
Re: Bah
D'autant plus qu'en contournant ce dispositif anti copie, je me mets dans l'illégalité.
je ne pense pas car c'est à des fins d'interopérabilité avec ton lecteur cd embarqué.
De plus tu as droit à ta copie de sauvegarde...
.
[ Répondre ]
/dev/cdrom
re-vérifie la justesse du lien symbolique /dev/cdrom
il pointe vers /dev/hda ce qui me surprend un peu...
à moins que ce soit une machine de gros bidouilleur fou, on ne trouve jamais de cdrom en master sur le premier bus ide. (mais c'est possible tout de même)
<newbie_area>
si ton lecteur est sur le premier bus (sur la meme nappe que le disque dur) il a de forte chance d'être en /dev/hdb
s'il est tout seul sur la 2 eme nappe, il sera soit en /dev/hdc soit en /dev/hdd
</newbie_area>
je prends pour acquis que c'est un lecteur ide et non scsi ou usb...
[ Répondre ]
[ Précédent :: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 :: Suivant ]



alias ?
et en mettant un alias sur le vieux serveur
test: test@adr_ip_du_nouveau_serveur
sans oublier de lancer newaliases
[ Répondre ]