テストエージェントのクレイジーキャッシュ
皆さん、ごきげんよう。
次のような問題が発生しました。
システム内に32の論理プロセッサを持ち、それぞれ32の最適化用エージェントを使用（さらに40のリモートエージェントを使用）
各エージェントは、2〜2.6GBの全く不十分なサイズのキャッシュをあっという間に作り上げ、1日で合計70GB以上になってしまいました！キャッシュ自体は削除されず、常に増え続けています。この狂気の沙汰を止めたのは、ディスクの容量が足りなくなったことだ。その後、エージェントは愚かにも動かなくなる。
設問は以下の通りです。
このような問題に直面された方はいらっしゃいますか？どのように対処すればいいのでしょうか？このようなキャッシュサイズの原因は何でしょうか？
servicedeskにリクエストを書きましたが、今のところ沈黙です。
キャッシュのサイズは生成されたティックの数に依存します（つまり、テスト期間と文字数が長いほど、キャッシュは大きくなります）。
あなたの場合、おそらく主な問題はエージェントの数です。現在（ビルド 1495）では、各エージェントが独自の キャッシュインスタンスを使用しているからです
キャッシュスペースは、エージェントのダウンタイムが5分経過すると解放されます。
さらに、テスターエージェントのティック履歴は、クラウドで使用している場合、容量がかかります（ティック履歴も最終的にはクリーンアップされますが、数日から数週間単位で実行されます）。
ちなみに、クラウドエージェントとローカルエージェントは別物です。写真では、同じコンピュータ上のクラウドエージェントが、ローカルネットワークのファームに追加されています - Voilà!2つのコアと4つの論理プロセッサを持つプロセッサで8つのテストエージェントを得ました（そうすることに価値があるかどうかは別の問題です）。
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
テスターには設定が一切ないので、自分のシステムに最適化することは不可能です。出力では、膨大な数の小ファイルが書き換えられ、ハードディスクが酷使されています（システム内の32エージェントでSSD 120GBで最大800GB/日）。
ポータブルモードで4種類のテスターを異なる物理ドライブで動作させることで部分的に解決しました。テスターが大量のメモリを放置しているため、RAMディスケを含む。
ちなみに、ラムディスク上にキャッシュを持つエージェントを実行すると、パフォーマンスが最大で3倍向上することがあります。それは改めてテスターの組織のあり方の嫌らしさを指摘するものだ。
ちなみに、クラウドエージェントとローカルエージェントは別物です。写真では、同じコンピュータ上のクラウドエージェントが、ローカルネットワークのファームに追加されています - Voilà!2つのコアと4つの論理プロセッサを持つCPUで8つのテストエージェントを得ました（そうするべきかどうかは別の問題です）。
これは、テスター組織の（開発者を許す）愚かさであり、エージェントの数が利点から問題に転化しているのである。
テスターには設定が一切ないので、自分のシステムに最適化することは不可能です。出力では、膨大な数の小さなファイルが上書きされ、ハードディスクが酷使されています（システム内の32エージェントでSSD 120GBで1日800GBまで）、面白いことに、この間コアはアイドル状態のままです。
...
ちなみに、フレームディスク上にキャッシュを持つエージェントを実行すると、パフォーマンスが最大で3倍向上することが多いんですよ。それは改めてテスターの組織のあり方の嫌らしさを指摘するものだ。
...
サービスデスクに書き込む。
ドライブから数ギガバイトのデータを読み込まなければならないのは、「嫌な組織」なのか？平均速度200mbpsのssdから1gbのデータを読み出すだけでも5秒かかる。もし、4-32人のエージェントがいたら？
技術的な面を考えるだけなんですね。何もかもが無料ではないし、技術的な要件をゼロに掛けることもない。
技術的なソリューションとエージェントの最適化のレベルは驚くべきもので、私たちは膨大な量の作業を行い、すべてのプロセスからミリ秒単位でスクラッチしました。データボリュームを忘れてはいけません。RAMを増やし、より大きなSSDを入れ、フレームディスクを入れれば、すべてが加速されるのです。
いずれも価格はすでにリーズナブルですが、解決されるクラスとボリュームには本格的な取り組みが必要です。
各エージェントは、2～2.6GBという全く不十分なサイズのキャッシュをどんどん蓄積し、1日で合計70GB以上！キャッシュは自分では削除せず、常に増え続けている。狂気の沙汰を止めたのは、ディスク容量が足りなくなったことだ。その後、エージェントは愚かにも動かなくなる。
こんなボリュームで何をキャッシュするんだ！？
データキャッシュはすべてOKです。ディスクに収め、メモリに保存して再放送を待ちます。同じエージェントでの再計算がいかに速いかに注目してください（効果を示すために1つのエージェントと1回の実行を取ります）。
もうひとつ、私たちはディスクの扱いを非常に慎重に行っています。大きな倍率で書き、ssdディスクの特殊性を明確に理解しています。
トレーダーは通常、個人的に生成した大きなログが約10Gバイトあることに気づかず、フォルダのサイズを確認することを好みます。
4種類のテスターをポータブルモードで異なる物理ディスクで動作させることで一部解決しました。テスターが大量のメモリを放置して いるため、RAMディスケを含む。
ちなみに、ラムディスク上にキャッシュを持つエージェントを実行すると、パフォーマンスが最大で3 倍向上することがあります。それはまたしてもテスターの組織のいやらしさを指摘するものだ。
エージェントの最適化レベルが「驚異的」なら、RAM-ディスクの構成で性能が何倍にもなる理由は何でしょうか？私の考えでは、不快ではあるが、論理的な質問である。
ZS エージェントのログを消去するソフトが必要ですね。そんな量では意味がない。Print+Alertは、最適化の際にユーザーがコード内で無効にする必要があります。
fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?
掲示板で発言するのではなく、自分の目で確かめてください。
エージェントの最適化が「すごい」レベルなのに、RAMdiskを整理して性能を倍増させる理由って何？私の考えでは、不快ではあるが、論理的な質問である。
キャッシュのためにRAMを100%食って、無期限に維持する権利はないからです。しかし、ある人が自分で32-64gbのディスクフレームを作り、そこにエージェントを移動させ、ディスクを積極的に扱うようになれば、たしかにディスクオペレーションは 何倍にも高速化される可能性はある。
しかし、具体的にはディスクオペレーションであり、「N倍で一気に」ではない。
テスターが驚くほどデータを処理することは、常時モードで使用し、バックグラウンドで新しい実行を待っているウォームアップされたテスターキャッシュから多くの利益を得ている人なら誰でもわかることです。実験では通常、数十回から数百回のテスター実行と、コードの再コンパイルが常時行われます。
HH エージェントのログを消去するソフトが必要です。そんなに大量には必要ないんです。そして、Print+Alertは最適化の際にユーザーがコードで無効にする必要があります。
テスターのログは自動的に消去されます。テスターを使う人はそれを知っている。そして、テスターのキャッシュは、テスターがもう使われないと理解した時点で、端末によって消去されます。
トピ主は「いつまでやるんだ」モードでスレッドを立ち上げ、根拠のない発言をした。もし、彼がきちんと収集したデータを提供していれば、データ収集の段階で50％の質問が落ちていただろう。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
皆さん、ごきげんよう。
次のような問題が発生しました。
システム内に32の論理プロセッサを持ち、それぞれ32の最適化用エージェントを使用（さらに40のリモートエージェントを使用）
各エージェントは、2-2.6GBの全く不十分なサイズのキャッシュをあっという間に構築し、合計で1日70GB以上にもなります！キャッシュはそれ自体を削除することはなく、常に増え続けています。この狂気の沙汰を止めたのは、ディスクの容量が足りなくなったことだ。その後、エージェントは愚かにも動かなくなる。
設問は以下の通りです。
このような問題に直面された方はいらっしゃいますか？どう対処すればいいのか？このような大きなキャッシュサイズの原因は何でしょうか？
servicedeskにリクエストを書きましたが、今のところ沈黙です。