Utilisez le Gestionnaire des tâches pour identifier une pression soutenue sur le processeur, la mémoire ou le disque pendant la charge de trading réelle. Réduisez le travail inutile des graphiques/de l'historique, un changement à la fois. Une utilisation CPU totale élevée peut compter, mais un seuil universel de 70 à 80 % ou un changement de priorité de processus n'est pas un remède vérifié aux déconnexions de Rithmic.
Conseils éducatifs sur le logiciel. Le trading comporte des risques. Lire les avertissements financiers et d'information.
Examiner la charge de travail
Ouvrez le Gestionnaire des tâches avec Ctrl+Maj+Échap. Examinez Processus pour l'utilisation du CPU et de la mémoire, et Performance pour le comportement du CPU, de la mémoire, du disque et du réseau. Microsoft décrit ces outils de surveillance. Un bref instantané pris au repos ne diagnostique pas un pic à l'ouverture du marché.
Notez la version de la plateforme, les espaces de travail actifs, le nombre de graphiques/indicateurs, les instruments et l'historique demandé. Un seul thread d'exécution saturé peut poser problème même lorsque le pourcentage global de CPU est modeste. Une pression sur la mémoire et la pagination du disque peuvent ressembler à un problème de CPU.
Réduire le travail délibérément
| Changement à évaluer | Ce qu'il faut observer |
|---|---|
| Supprimer les graphiques/indicateurs inutilisés | Réactivité de l'application et CPU sous une charge de données comparable |
| Réduire la plage d'historique initiale | Charge au démarrage et exhaustivité de l'analyse requise |
| Réduire les abonnements inutiles | Volume de traitement des données et instruments requis manquants |
| Ajuster le rafraîchissement/l'agrégation d'affichage pris en charge | Économie de ressources par rapport à la perte de détail d'analyse |
| Planifier les tâches lourdes en arrière-plan | Contention, sans affaiblir la sécurité ni la reprise |
Ne désactivez pas les données nécessaires à une stratégie et ne modifiez pas le comportement intrabarre simplement pour abaisser un graphique d'utilisation. Bookmap avertit que l'agrégation peut gêner la fonctionnalité MBO ; ATAS exige aussi des paramètres hôte/client concordants pour sa route par plugin.
Vérifier l'amélioration
Répétez la même charge de travail et comparez la pression sur les ressources, l'âge des cotations, la réactivité de l'application et les déconnexions journalisées. Annulez un changement inefficace. Conservez les journaux de diagnostic avant les mises à jour. Un VPS amélioré n'aide que si le goulot d'étranglement concerné est atténué ; des lignes de compte supplémentaires ne constituent pas à elles seules un modèle de dimensionnement des ressources.
Aucun changement de priorité, d'affinité, de pare-feu ou de stratégie d'alimentation n'a été effectué sur ce VPS. Un changement de priorité de processus doit suivre un besoin diagnostiqué et les recommandations prises en charge par la plateforme.
Questions fréquentes
Dois-je toujours définir la priorité de processus Haute ?
Non. Diagnostiquez le goulot d'étranglement et suivez les recommandations prises en charge par la plateforme.
Un CPU total faible exclut-il un goulot d'étranglement de traitement ?
Non. Un thread occupé, une pression sur la mémoire ou l'activité du disque peuvent quand même compter.
Dois-je supprimer tous les indicateurs d'order flow ?
Supprimez uniquement le travail inutile et vérifiez que la stratégie reçoit toujours les données requises.
Un benchmark de la plateforme sous charge a-t-il été réalisé ici ?
Non. Il s'agit d'une procédure de diagnostic mesuré, et non d'un test de performance revendiqué.