테스트 에이전트의 미친 캐시

 

모두에게 좋은 하루!

이 문제에 직면했습니다.

시스템에 32개의 논리 프로세서가 있음 - 최적화를 위해 각각 32개의 에이전트를 사용합니다(+ 40개 이상의 원격 에이전트).

각 에이전트는 하루에 총 70GB 이상에 달하는 2-2.6GB의 완전히 부적절한 크기의 캐시를 빠르게 확장합니다! 캐시 자체는 삭제되지 않으며 지속적으로 증가합니다. 이 광기는 디스크 공간이 부족하여 중지되었습니다. 그 후 에이전트는 멍청하게 작동을 멈 춥니 다.

실제 질문은 다음과 같습니다.

누구든지 그런 문제가 발생 했습니까? 그것을 처리하는 방법? 이러한 캐시 볼륨의 원인은 무엇입니까?

지금까지 서비스 데스크에 요청을 작성했습니다.

 
추신: 터미널 64비트, 최신 버전
 
alrane :

모두에게 좋은 하루!

이 문제에 직면했습니다.

시스템에 32개의 논리 프로세서가 있음 - 최적화를 위해 각각 32개의 에이전트를 사용합니다(+ 40개 이상의 원격 에이전트).

각 에이전트는 하루에 총 70GB 이상에 달하는 2-2.6GB의 완전히 부적절한 크기의 캐시를 빠르게 확장합니다! 캐시 자체는 삭제되지 않으며 지속적으로 증가합니다. 이 광기를 막는 유일한 방법은 디스크 공간이 부족하다는 것입니다. 그 후 에이전트는 멍청하게 작동을 멈 춥니 다.

실제 질문은 다음과 같습니다.

누구든지 그런 문제가 발생 했습니까? 그것을 처리하는 방법? 이러한 캐시 볼륨의 원인은 무엇입니까?

서비스 데스크에 요청을 썼고 지금까지 침묵했습니다.

캐시 크기는 생성된 틱 수에 따라 다릅니다(즉, 테스트 기간이 길고 심볼 수가 많을수록 캐시가 커짐).

귀하의 경우 가장 큰 문제는 아마도 상담원의 수일 것입니다. 이제(빌드 1495) 각 에이전트는 자체 캐시 인스턴스를 사용합니다!

캐시 공간은 에이전트 다운타임 5분 후에 해제됩니다.

또한 테스터의 에이전트에 대한 틱 기록은 에이전트가 클라우드에서 사용되는 경우 공간을 차지할 수 있습니다.

그건 그렇고, 클라우드 에이전트와 로컬 에이전트는 다른 에이전트입니다. 그림에서 동일한 컴퓨터의 클라우드 에이전트가 로컬 네트워크 팜에 추가됩니다 - Voilà! 2개의 코어와 4개의 논리 프로세서가 있는 프로세서에서 8개의 테스트 에이전트가 발견되었습니다(이 작업을 수행할 가치가 있는지 여부는 또 다른 질문입니다).

 
:

В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!

이것이 (개발자들이 나를 용서할 수 있음) 에이전트의 수가 장점에서 문제로 변할 때 테스터 조직의 어리석음입니다.

테스터에는 설정이 전혀 없으므로 시스템에 대한 작업을 최적화할 수 없습니다. 결과적으로 우리는 작은 파일을 미친 듯이 덮어 쓰는 하드 디스크의 강간을 얻었습니다 (시스템에 32 개의 에이전트가있는 120GB SSD에서 하루 최대 800GB까지 확인했습니다). 재미있는 점은 코어는 현재 유휴 상태입니다.

다른 물리적 디스크에서 휴대용 모드로 4개의 다른 테스터를 실행하여 문제를 부분적으로 해결했습니다. 포함 및 RAM 디스크, 왜냐하면 테스터는 많은 양의 메모리를 방치합니다.

그건 그렇고, 램디스크에 캐시가 있는 에이전트의 작업은 종종 성능을 최대 3배까지 향상시킵니다! 테스터 작업의 역겨운 조직을 다시 한 번 나타냅니다.

:

그건 그렇고, 클라우드 에이전트와 로컬 에이전트는 다른 에이전트입니다. 그림에서 동일한 컴퓨터의 클라우드 에이전트가 로컬 네트워크 팜에 추가됩니다 - Voilà! 2개의 코어와 4개의 논리 프로세서가 있는 프로세서에서 8개의 테스트 에이전트가 발견되었습니다(이 작업을 수행할 가치가 있는지 여부는 또 다른 질문입니다).

같은 이유로 이 작업을 수행해서는 안 됩니다. 커널도 디스크의 데이터를 기다리지만 이미 이중 볼륨에 있습니다. 나는 이것이 성능을 감소시킬 것이라고 생각합니다.
 
alrane :
이것이 (개발자들이 나를 용서할 수 있음) 에이전트의 수가 장점에서 문제로 변할 때 테스터 조직의 어리석음입니다.

테스터에는 설정이 전혀 없으므로 시스템에 대한 작업을 최적화할 수 없습니다. 결과적으로 우리는 작은 파일을 미친 듯이 덮어 쓰는 하드 디스크의 강간을 얻었습니다 (시스템에 32 개의 에이전트가있는 120GB SSD에서 하루 최대 800GB까지 확인했습니다). 재미있는 점은 코어는 현재 유휴 상태입니다.

...
그건 그렇고, 램디스크에 캐시가 있는 에이전트의 작업은 종종 성능을 최대 3배까지 향상시킵니다! 테스터 작업의 역겨운 조직을 다시 한 번 나타냅니다.

...

서비스 데스크에 작성하십시오 .

 
이미 썼습니다. 베스트톨쿠.
 

디스크에서 몇 기가바이트의 데이터를 읽어야 하는 것이 "역겨운 조직"입니까? 초당 평균 200mb의 속도로 ssd에서 1GB의 데이터를 읽는 것만으로도 5초가 걸립니다. 그리고 거기에 4-32명의 에이전트가 있다면?

문제의 기술적 측면만 생각하면 됩니다. 공짜는 없으며 기술 요구 사항에 0을 곱하는 사람은 없습니다.

기술 솔루션과 에이전트의 최적화 수준은 놀랍습니다. 우리는 여기에 엄청난 양의 작업을 투입했고 모든 프로세스에서 밀리초를 긁어모았습니다. 데이터 볼륨을 잊지 말고 더 많은 RAM을 설치하고 대용량 SSD를 설치하고 RAM 디스크를 설치하면 모든 것이 가속화됩니다.

이 모든 것에 대한 가격은 이미 수용 가능하며, 해결된 문제의 종류와 양에는 진지한 접근이 필요합니다.

 
alrane :

각 에이전트는 하루에 총 70GB 이상에 달하는 2-2.6GB의 완전히 부적절한 크기의 캐시를 빠르게 확장합니다! 캐시 자체는 삭제되지 않으며 지속적으로 증가합니다. 이 광기를 막는 유일한 방법은 디스크 공간이 부족하다는 것입니다. 그 후 에이전트는 멍청하게 작동을 멈 춥니 다.

그러한 볼륨에 캐시할 수 있는 것은 무엇입니까?!
 
fxsaber :
이러한 볼륨에 캐시할 수 있는 것은 무엇입니까?!
일반적으로 트레이더는 폴더 크기를 확인하고 자신이 직접 생성한 10GB의 방대한 로그가 있다는 사실을 인지하지 못하는 것을 선호합니다.

데이터 캐시가 있으면 우리는 괜찮습니다. 그리고 우리는 그것을 디스크에 보관하고 반복 실행을 예상하여 메모리에 저장합니다. 동일한 에이전트에 대한 재계산이 얼마나 더 빠른지 주목하십시오(효과를 입증하기 위해 하나의 에이전트와 하나의 패스를 사용하십시오).



그러나 우리는 디스크 작업을 매우 드물게 합니다. 우리는 큰 배수로 작성하고 ssd 드라이브의 기능을 명확하게 이해합니다.
 
Renat Fatkhullin :
일반적으로 트레이더는 폴더 크기를 확인하고 자신이 직접 생성한 10GB의 방대한 로그가 있다는 사실을 인지하지 못하는 것을 선호합니다.
각 지역 에이전트당 약 기가바이트의 현금이었습니다. 나는 아직도 그런 양으로 거기에 무엇을 저장할 수 있는지 이해하지 못합니까?
알란 :
다른 물리적 디스크에서 휴대용 모드로 4개의 다른 테스터를 실행하여 문제를 부분적으로 해결했습니다. 포함 및 RAM 디스크, 왜냐하면 테스터는 많은 양의 메모리를 방치 합니다.

그건 그렇고 , 램디스크에 캐시가 있는 에이전트의 작업은 종종 성능을 최대 3배까지 향상시킵니다 ! 테스터 작업의 역겨운 조직을 다시 한 번 나타냅니다.

에이전트 최적화 수준이 "놀라운" 경우 RAM 디스크를 구성하면 성능이 몇 배 향상되는 이유는 무엇입니까? 제 생각에는 논리적인 질문이지만 불쾌한 질문입니다.

추신: 에이전트 로그를 지우는 프로그램이 필요합니다. 그런 양에서는 쓸모가 없습니다. 예, 최적화하는 동안 코드에서 사용자가 인쇄 + 경고 를 비활성화해야 합니다.

 

fxsaber :
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?

그리고 당신은 포럼 성명서로 작업하는 대신 자신을 바라봅니다.

에이전트 최적화 수준이 "놀라운" 경우 RAM 디스크를 구성하면 성능이 몇 배 향상되는 이유는 무엇입니까? 제 생각에는 논리적인 질문이지만 불쾌한 질문입니다.

캐시용 RAM을 100% 먹고 무기한으로 보관할 권리가 없기 때문입니다. 그러나 사람이 32-64GB의 램 디스크를 만들고 거기에 에이전트를 전송하고 디스크로 적극적으로 작업하기 시작한 경우 예 - 때때로 디스크 작업 을 가속화 할 수 있습니다.

그러나 그것은 디스크 작업이며 "모든 N 번 즉시"가 아닙니다.

테스터가 데이터와 함께 놀랍게 작동한다는 것은 지속적으로 데이터를 사용하고 테스터의 따뜻한 캐시에서 많은 이점을 얻고 백그라운드에서 새로운 실행을 기다리는 모든 사람에게 분명합니다. 일반적으로 실험은 코드를 지속적으로 재컴파일하면서 수십 수백 개의 테스터를 실행하는 것입니다.

추신: 에이전트 로그를 지우는 프로그램이 필요합니다. 그런 양에서는 쓸모가 없습니다. 예, 최적화하는 동안 코드에서 사용자가 인쇄 + 경고를 비활성화해야 합니다.

테스터의 로그는 자동으로 삭제됩니다. 테스터를 사용해 본 사람은 알 것입니다. 그리고 테스터가 더 이상 사용되지 않는다는 것을 깨닫는 즉시 테스터의 캐시는 터미널 자체에 의해 지워집니다.

Topikstarter는 "얼마나 오래?"에서 주제를 시작했습니다. 그리고 근거 없는 주장을 여러 번 했다. 수집된 데이터를 제대로 제공했다면 데이터 수집 단계에서 질문의 50%가 사라집니다.