Proper paramètres pour éviter l'utilisation intensive de SWAP

Bonjour,

Je fais tourner StrategyQuant sur un ordinateur quadricœur avec 8G de RAM physique. J'ai alloué 3 threads à StrategyQuant et lui ai permis d'utiliser 7G de RAM, c'est-à-dire que j'ai utilisé l'option Java VM suivante au démarrage du programme :

StrategyQuant64.exe -J-Xmx7g

Mon problème est que lorsque l'évolution progresse, StrategyQuant utilise beaucoup de mémoire SWAP (fichier de page sur le disque dur) pour éviter de dépasser la limite physique de RAM. Cela ralentit considérablement les choses. Même si je vais passer mon disque dur en SSD et augmenter la taille de ma RAM, il y aura toujours un goulot d'étranglement à un moment ou à un autre.

Ma question est la suivante : comment l'utilisation de la mémoire évolue-t-elle approximativement en fonction des paramètres suivants ? Et y a-t-il un ensemble de paramètres recommandés/de référence sur la base desquels nous pouvons ajuster en fonction des spécifications du matériel et de la règle d'échelonnement ? 

* Nombre de fils

* Taille de la population

* Nombre maximal de générations (en supposant qu'il n'y ait pas de stagnation) 

* Nombre maximum de stratégies à conserver dans la banque de données

* Nombre total de barres pour les données historiques IS et/ou OOS

* Nombre de blocs de construction activés

* Profondeur maximale de l'arbre pour la génération d'une population aléatoire

* Autre chose ?

Merci !

-Zhong

Bonjour,

il ne s'agit pas d'un échange de mémoire système, SQ utilise des fichiers pour stocker des données stratégiques afin de ne pas avoir à les garder toutes en mémoire et aussi pour éviter les plantages.

En général, il enregistre chaque stratégie dans la banque de données sous forme de fichier, et il enregistre la liste des transactions (ce qui consomme le plus de mémoire) dans un fichier temporaire.

La seule chose qui influe réellement sur ce point est le nombre de stratégies dans les banques de données, qu'il s'agisse de la banque de données des résultats ou de la dernière génération.

Vous pouvez donc le réduire en diminuant la taille de la population et le nombre total de banques de données, mais la meilleure solution consiste à acheter un disque SSD plus rapide.

Mais même avec un disque dur normal, cela ne devrait pas prendre trop de temps, le processus le plus long étant l'exécution du backtest, qui est plusieurs fois plus coûteux en temps que l'écriture/la lecture de fichiers sur le disque.

Marquer,

Merci pour l'excellent produit et la réponse rapide !

J'ai installé un SSD de 240GB hier et j'ai migré mon Windows 7 professional 64-bit dessus, ainsi que StrategyQuant. J'ai lancé l'évolution pendant la nuit, cette fois en limitant à seulement 2 threads (j'ai un quad-core), 250 population size, 2000 pour la banque de données avec des règles assez strictes (donc je soupçonne que seul un petit nombre peut y entrer), et 6G maximum RAM use setting (j'ai 8G total RAM). Malheureusement, ce matin, la fenêtre StrategyQuant ne peut plus être affichée. Windows répond toujours à certaines commandes, mais de manière très lente et semi-froide. StrategyQuant semble être minimisé et le fait de le restaurer ou de le maximiser ne fait pas apparaître la fenêtre. "L'explorateur de système montre que la RAM est utilisée à 76% et le CPU à 55%, StrategyQuant utilise 4071MB RAM, et 5026MB SWP (voir pièce jointe).

En ce qui concerne l'utilisation du SWAP, je pense que Java VM le fait automatiquement. Si j'ai défini le paramètre pour limiter Java VM à 6G maximum mais que le programme utilise en réalité 12G, je pense que Java VM gérera automatiquement la permutation entre la RAM physique et le fichier de pages sur le disque pour les 6G supplémentaires. Bien sûr, il s'agit d'une vision simpliste - même si la limite de RAM est plus élevée que l'utilisation réelle, il est possible qu'il y ait encore des échanges.

Je vais essayer de réduire la taille de la population avec un seul fil cette fois-ci.

Enfin, une question : lorsque j'utilise 2 threads, l'utilisation de la RAM double-t-elle approximativement (au moins pour la partie qui stocke la population actuelle), en supposant qu'aucune limite ne vienne du paramètre de la ligne de commande ?

P.S. Je viens de terminer le processus StrategyQuant par la force, et maintenant l'utilisation de la RAM revient à 22% et le CPU à 2%. Le système est à nouveau réactif. Ce bureau est dédié à StrategyQuant, donc aucun autre processus coûteux n'était en cours d'exécution - à l'exception de TeamViewer pour l'accès à distance qui prend environ 500 Mo de RAM et 1 à 3% de CPU. Y a-t-il un risque que TeamViewer ou une autre application de bureau à distance ne fonctionne pas bien avec StrategyQuant ?

Merci,

-Zhong

Fichier : 2015-04-21_07-55-24.png

Juste pour ajouter des informations supplémentaires. 

Le test de nuit que j'ai mentionné plus haut a utilisé les paramètres suivants :

Fichier : 2015-04-21_09-55-03.png

J'ai effectué des tests approfondis pendant des semaines et je peux vous dire ce qui suit lorsque je génère des stratégies avec ces paramètres :

1 seul fil ( !)

14 ans de données

Délai de 30 millions d'euros

Mode "Timeframe only" (période sélectionnée uniquement)

Tous les indicateurs utilisés

250 population (mais facteur de décimation de 10 pour la génération aléatoire initiale, de sorte que 2500 sont générés au départ)

nombre illimité de générations, mais arrêt de l'évolution si l'aptitude stagne pendant 3 générations

stockage d'un maximum de 50 stratégies dans la base de données

Vous pourrez utiliser 4 Go par instance en utilisant cette ligne de lancement et vous ne manquerez pas de mémoire dans Java et SQ ne commencera pas à échanger des données : StrategyQuant64.exe -J-server -J-Xmx4g -J-XX:+UseParallelGC -J-XX:+UseParallelOldGC -J-XX:+DisableExplicitGC -J-XX:+AggressiveOpts

Dès que vous augmentez la taille de la population au-delà de 250, l'utilisation de la RAM augmente considérablement, je ne sais pas pourquoi, mais c'est comme ça.

Lorsque vous passez de M30 à M15, l'utilisation de la RAM double presque, de même si vous passez ensuite à M5 et de nouveau à M1 (il est absolument impossible de générer avec cela à long terme sans assigner au moins 32GB RAM à l'instance avec seulement 1 thread !)

Si vous autorisez plus d'un thread, l'utilisation de la RAM double également entre 1 et 2 threads et augmente considérablement si vous en autorisez davantage, alors que l'utilisation du CPU n'est pas vraiment meilleure. Lors de la génération de stratégies (j'ai déjà signalé ce problème en tant que "bug"), SQ utilise presque toujours un seul cœur en moyenne. Il n'est donc pas vraiment utile d'assigner plus d'un thread lors de la génération de stratégies, cela ne fait que gaspiller de la RAM (pour l'Optimizer par contre, il utilise tous les cœurs très bien).

Donc vous voyez, en utilisant M1, vous n'aurez aucune chance avec 6GB de RAM, absolument pas. Essayez les choses suggérées ci-dessus pour l'instant et vous pourrez faire fonctionner SQ pendant des jours sans problème. A mon avis, SQ doit devenir BEAUCOUP PLUS EFFICACE pour être vraiment utilisable. J'ai de grands espoirs pour la V4 avec cela....

Merci geektrader pour cette réponse détaillée ! C'était vraiment utile. Je suis en train d'essayer vos suggestions ; de plus, demain, j'aurai 16G de RAM à bord pour améliorer la situation.

J'ajouterai deux informations :

(1) J'ai fait une erreur plus tôt en incluant les données de la barre d'une minute de 4 autres symboles dans les "Données supplémentaires pour les tests". Je pensais qu'il s'agissait d'un test après l'évolution, mais j'avais manifestement tort - les performances sur les données supplémentaires ont été calculées en même temps que les données principales pendant l'évolution. En décochant les données supplémentaires, l'évolution est beaucoup plus rapide et l'utilisation de la RAM plus faible.

(2) Étant donné que StrategyQuant effectue de nombreuses lectures/écritures sur le disque pendant son exécution (plusieurs Go de fichiers temporaires sont écrits sur le disque pendant l'évolution), l'utilisation d'un disque SSD est fortement recommandée. Mais si l'on dispose de suffisamment de RAM, une autre possibilité d'accélération consiste à exécuter l'ensemble du programme sur un disque virtuel RAM (qui peut être facilement créé par exemple avec ImDisk), qui sera plusieurs fois plus rapide que le SSD. L'inconvénient est bien sûr qu'il y a moins de RAM disponible pour le programme lui-même, et la RAM est volatile, de sorte qu'en cas de coupure de courant ou de redémarrage/arrêt inattendu, tous les résultats sont perdus. Cela vaut quand même la peine d'essayer - je le ferai quand le 16G arrivera et je rapporterai ici si j'obtiens de bons résultats.

-Zhong