CPU – Page 2 – Les Mondes de Cyborg Jeff

FCPX (Final Cut Pro X) très lent, j’approche de la solution !

31 mai 2013 cyborgjeff Commentaires 15 commentaires - Post Views: 7 509

Depuis la fin de l’année 2012, et le passage à la version 10.0.5 de FCPX, je rencontre d’importants problèmes de lenteur d’export des mes montages vidéo. Je cherche régulièrement des réponses sur Internet et je pratique de nombreux tests. Si j’ai pensé tout un temps que le problème était uniquement lié à ma génération d’iMac sous OSX 10.6.8 (Core i7, 8go RAM, ATI 6770M 512mo). Après des tests plus approfondi sur mon Mac Book Pro de génération suivante (OSX 10.7.5, Core i7, 8go, ATI 6770M 1go), je me rends compte que mon soucis n’est pas uniquement lié à ma machine.

Pour résumer depuis le passage à la version 10.0.5 de FCPX, le temps de rendu des mes vidéos montée en HD prenait plus de 8 heures pour des montages de moins de 10 minutes… Parfois montant jusqu’à 72 heures lorsque j’appliquais mon plugin de correction d’image RedGiant Magic Bullet Looks. Au par avant les temps de rendu était beaucoup plus correcte, jamais plus de 2 heures. Les tests étaient claire, les processeurs du Core i7 étaient peu sollicité et les accès disques anormalement faible. Il semble effectivement que les nouvelles versions de FCPX privilégient plus le calcul du rendu sur le processeur GPU (carte graphique) que sur celui du CPU, mais malgré cela, j’ai eu beaucoup de difficulté à collationner les témoignages d’autres personnes rencontrant un problème similaire.

Hier pourtant, j’ai pu lire de nouvelles données qui ont pu sensiblement me faire avancer. Plutôt que de choisir l’option de sortie « Dispositifs Apple 720p », j’ai choisi l’option « Render Master ». Une option apparue entre temps dans ce menu qui exporte un fichier imposant (1go/minutes) mais qui se montre beaucoup plus rapide. Mon projet en cours de 15 minutes avec effets Looks en était à 40% au bout de 24h par la méthode utilisée jusqu’ici, il s’est exporté en 8 heures.

…

Lire la suite Lire la suite

Cyborg Jeff vs Robots

24 mai 2012 cyborgjeff Commentaires 13 commentaires - Post Views: 223

Ok, après de longues soirées, j’ai donc pu faire redescendre à la normal la charge CPU du serveur Infomaniak et rejoindre mes « copains » du serveur mutualisé. Le combat fut long, stressant et dans la mesure où une fois de plus, je me suis retrouvé seul au monde avec mon problème, je vais en profitez pour vous en faire partager les solutions, puisque déjà quelques autres internautes commencent à rencontrer de problèmes similaires.

Rappel des faits, début du mois, mon hébergement chez Infomaniak devait être isolé car quelques choses saturait le serveur web… et à moi d’en trouver la cause et l’éradiquer. Pas de malware, mise à jour de WordPress et plugins, rien n’y fait, je finis par constater un taux anormal d’appel dans les logs sur une seul et unique page du blog, plus de 10x par secondes et venant de serveurs BingBot officiels Microsoft. La raison reste toujours un mystère, mais mes lectures ont pu montrer d’autres cas similaires. Bug de l’outil, tentative de détournement pour saturer les serveurs…

Tout d’abord, j’ai donc installé un plugin de gestion de cache des pages à la demande d’Infomaniak. Celui-ci n’a pas vraiment fait diminuer la charge CPU, et m’enquiquine plus qu’autre chose d’ailleurs.

Après de nombreux tests, j’ai finalement interdit à BingBot et MSNBot de se rendre sur tout le site contenant la page à problème. Radicale, mais le contenu de celui-ci ne souffrira pas de ce nom référencement… Ceci dit cette solution est à mon goût trop agressive.

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(msnbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* – [F,L] # On interdit alors l’accès à la page

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(bingbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* – [F,L] # On interdit alors l’accès à la page

La solution s’avère efficace, puisque la charge serveur diminue alors de suite, néanmoins les logs restent surchargés, j’adapte donc avec un fichier ROBOTS.TXT qui placé à la racine du site impose aux différents bots ce qu’il peuvent indexer ou non… 24h plus tard, les résultats sont efficaces, mon fichiers LOG de 40mo est passé à 1,5mo !

User-agent: *
Disallow: /wp-*
Disallow: /*.php$
Disallow: /*.js$
Disallow: /*.inc$
Disallow: /*.css$
Disallow: /*%26layout=
Disallow: /*xoops_url

J’impose donc de ne pas indexer tous répertoires ou fichiers commençant par wp- à savoir des fichiers critiques à WordPress, les fichiers .php, .js ou .css et propre à ce cas les urls contenant la chaine de caractère %26layout= ou xoops_url.

Bon, j’espère être tranquille jusqu’à l’année prochaine mantenant !

Allé, pour vous donner un peu de coeur à l’ouvrage… tout cela me rappelle ce morceau de musique écrit en 2002 : Cyborg Jeff – We are the Bots !