Bulut senkronizasyon hataları - sayfa 2

[Slava]

10 dakika ile 20 dakika arasındaki fark nedir? Farklı değil. Tek arama için 10 dakika son derece uzun. Yanlış yazılmış EA testi mi istiyorsunuz? Sorun yok. Ancak sorunlarınızı genel Bulut sunucusunda genişletmeyin. Diğer kullanıcılar da Bulut sunucusunu kullanmak istiyor. Yerel aracıları ve uzak aracıları herhangi bir kısıtlama olmaksızın kullanabilirsiniz - Rica ederim

[Alain Verleyen]

cowil :

Merhaba Stringo,

Öncelikle bilgi için teşekkürler.

Ancak, bunun için MetaQuotes mantığıyla ilgileniyorum. Büyük miktarda "Every Tick" verisi kullanılıyorsa (örneğin, 2003.1.1 -> 2013.1.1) ve Uzmanın optimize edilmesi oldukça karmaşıksa, tek bir optimizasyon yinelemesinin sonuç vermesi genellikle 10 dakikadan uzun sürer. meydana gelir . MetaQuotes'un zaman aşımı olarak 10 dakikalık bir süre seçmesinin özel bir nedeni var mı? Ayrıca, bulut kullanıcısının bu zaman aşımını artırmasının herhangi bir yolu var mı yoksa bu MetaQuotes tarafından "bağlantılı" mı?

dize :
Yalnızca Bulut Aracılarında sonsuz döngü algılandı. Çağrılardan biri (OnInit, OnDeinit, OnTick, OnTimer vb.) 10 dakikadan fazla çalışıyorsa

Bu tek bir optimizasyon değil, bir işleve yönelik bir sinyal çağrısıdır.

[cowil]

angevoyageur :
Bu tek bir optimizasyon değil, bir işleve yönelik bir sinyal çağrısıdır.

Ah - benim hatam - bir olay işleyiciye yapılan tek bir çağrıdan ziyade tek bir optimizasyon yinelemesinden bahsettiğimizi bir şekilde kafamda vardı (Stringo özellikle tek bir olay işleyici çağrısından bahsetmiş olsa da). 10 dakikadan uzun süren bir olay işleyicisine yapılan tek bir çağrı gerçekten saçma olurdu. Alçakgönüllü özürlerim - beynim kararmış olmalı - beyni dinlendirme zamanı. :)

Mmmmm - yani Uzmanımda OnTick()'in bir aramayı tamamlamasının bazen 10 dakikadan uzun sürmesine neden olan garip bir şey olmalı. Kazmaya başlama zamanı...

Her neyse, yardımlarınız için tekrar teşekkürler arkadaşlar!

[Slava]

angevoyageur :
Bu tek bir optimizasyon değil, bir işleve yönelik bir sinyal çağrısıdır.

Aynen öyle. Bulut aracılarından birinde tek bir arama 10 dakikadan uzun olamaz

[cowil]

Merhaba,

Hâlâ kazıyor ama bir şey bulmakta zorlanıyor. Uzmanımın yerel Aracılarımda kusursuz bir şekilde optimizasyon yapması (yani, Temsilcilerimin ilerleme yüzdelerinin hiçbiri, OnTick() işlevimde bir tür sonsuz döngü olsaydı böyle olacağını düşündüğüm herhangi bir zamanda duraklar veya durur) en az 10 dakika veya daha fazla süren) gerçekten zorlaştırıyor.

Merak ettiğim bir şey var - hata mesajının sonundaki PR numarası neyi gösteriyor (yani ".... uzman 600 saniyede MQL5 Cloud Network tarafından reddedildi ( PR116 )". Bu konuyu aydınlatabilecek biri var mı?

Bu konudaki yardımlarınız için şimdiden teşekkürler.  

[Alain Verleyen]

cowil :

Merhaba,

Hâlâ kazıyor ama bir şey bulmakta zorlanıyor. Uzmanımın yerel Aracılarımda kusursuz bir şekilde optimizasyon yapması (yani, Temsilcilerimin ilerleme yüzdelerinin hiçbiri, OnTick() işlevimde bir tür sonsuz döngü olsaydı böyle olacağını düşündüğüm herhangi bir zamanda duraklar veya durur) en az 10 dakika veya daha fazla süren) gerçekten zorlaştırıyor.

Merak ettiğim bir şey var - hata mesajının sonundaki PR numarası neyi gösteriyor (yani ".... uzman 600 saniyede MQL5 Cloud Network tarafından reddedildi ( PR116 )". Bu konuyu aydınlatabilecek biri var mı?

Bu konuda yardımlarınız için şimdiden teşekkürler.  

PR, özel bir birleşik yönteme göre hesaplanan bir aracının performans derecesidir. Bir acentenin PR'ı ne kadar yüksekse, görevini o kadar hızlı yerine getirir ve sonuç olarak birim zaman başına kiralama fiyatı o kadar yüksek olur.

Daha fazla bilgi için buraya bakın.

[cowil]

angevoyageur :
Daha fazla bilgi için buraya bakın.

Ah - bu kesinlikle her şeyi açıklıyor. Yardımın için teşekkürler!

[cowil]

Merhaba,

Hafta sonu boyunca kodumu incelemek için saatler harcadıktan sonra, Uzman kodumda sonsuz bir döngü olasılığının ortaya çıkabileceği hiçbir yer bulamadım. Ve bu süreçte, Expert'imin sonsuz döngü sorunları olsaydı, Expert'imi optimize etmek için yerel aracılarımı kullanırken bunun belirgin hale geldiğini görmem gerektiğine giderek daha fazla ikna oldum. Yukarıda bahsettiğim gibi, yerel temsilcilerim, Uzmanımın optimizasyonu sırasında hiçbir aşamada duraklama yapmaz - bırakın on dakika veya daha uzun bir süre için.

Sorunların Uzmanımdan kaynaklanmadığına ikna olduktan sonra diğer alternatifleri incelemeye başladım. Görebildiğim tek mantıklı alternatif, ya aracıların kendileriyle (yani hatalar) ya da üzerinde çalıştıkları kutularla ilgili sorunlar olduğuydu. Bu alternatiflerden ikincisi suçlu gibi görünüyor.

Çalışabildiğim kadarıyla, insanlar her türlü kutuda bulut aracıları çalıştırıyorlar. Ayrıca bu bulut aracılarının hepsinin Windows tabanlı olduğunu varsayıyorum. Bundan bahsetmemin nedeni, Windows'un tüketici sürümleriyle ilgili kendi kişisel deneyimim, herhangi bir süre boyunca bozulduklarında kötü bir şekilde kararsız olmaları, ciddi işleme talepleri ile karşı karşıya kaldıklarında yavaşlama ve hatta ele geçirme eğiliminde olmalarıdır.

Gerçekleştirmeye çalıştığım Optimizasyonlar, 6-7 yıllık " Her Kene " verileri üzerinde çalışan, yani makul işleme ve bellek talepleri gerektiren oldukça karmaşık bir Uzmanla ilgilidir. Bu görevi üstlenen buluttaki aracıların yeterince belirtilmediğinden şüpheleniyordum - özellikle de Windows kutuları olacaklarını düşünürsek.

Bu yüzden OnInit() olay işleyicime aşağıdaki kod satırını koydum:

     // Check optimisation agent stats...
     if ( MQL5InfoInteger ( MQL5_OPTIMIZATION ) && TerminalInfoInteger ( TERMINAL_MEMORY_PHYSICAL ) < 32000 )
         return ( INIT_AGENT_NOT_SUITABLE );

TERMINAL_MEMORY_PHYSICAL kullanmamın nedeni, diğer bellek seçeneklerinin: TERMINAL_MEMORY_TOTAL ve TERMINAL_MEMORY_AVAILABLE, size yalnızca ana bilgisayarın işlemcisinin toplam, kullanıcı modu sanal adres alanını sağladıklarından (yani, 32 bit işlemci için 4 GB veya 8 TB için) fazla kullanılmamasıdır. 64 bit işlemci). 8 TB belleğe sahip 64 bit makineler hayal edemiyorum - en azından henüz değil. :) TERMINAL_CPU_CORES düşündüğüm bir başkasıydı ama sonunda sadece bellek testi yapmaya karar verdim çünkü yeterli miktarda belleğe sahip herhangi bir kutunun diğer tüm önemli alanlarda düzgün bir şekilde belirtileceğini varsayıyordum .

Ve tahmin et ne oldu - artık sorun yok! Tüm optimizasyonlarım şimdi iyi çalışıyor. :)

[Clock]

cowil :

Merhaba,

Hafta sonu boyunca kodumu incelemek için saatler harcadıktan sonra, Uzman kodumda sonsuz bir döngü olasılığının ortaya çıkabileceği hiçbir yer bulamadım. Ve bu süreçte, Expert'imin sonsuz döngü sorunları olsaydı, Expert'imi optimize etmek için yerel aracılarımı kullanırken bunun belirgin hale geldiğini görmem gerektiğine giderek daha fazla ikna oldum. Yukarıda bahsettiğim gibi, yerel temsilcilerim, Uzmanımın optimizasyonu sırasında hiçbir aşamada duraklama yapmaz - bırakın on dakika veya daha uzun bir süre için.

Sorunların Uzmanımdan kaynaklanmadığına ikna olduktan sonra diğer alternatifleri incelemeye başladım. Görebildiğim tek mantıklı alternatif, ya aracıların kendileriyle (yani hatalar) ya da üzerinde çalıştıkları kutularla ilgili sorunlar olduğuydu. Görünüşe göre bu alternatiflerden ikincisi suçlu gibi görünüyor.

Çalışabildiğim kadarıyla, insanlar her türlü kutuda bulut aracıları çalıştırıyorlar. Ayrıca bu bulut aracılarının hepsinin Windows tabanlı olduğunu varsayıyorum. Bundan bahsetmemin nedeni, Windows'un tüketici sürümleriyle ilgili kendi kişisel deneyimim, herhangi bir süre boyunca bozulduklarında kötü bir şekilde kararsız olmaları, ciddi işleme talepleri ile karşı karşıya kaldıklarında yavaşlama ve hatta ele geçirme eğiliminde olmalarıdır.

Gerçekleştirmeye çalıştığım Optimizasyonlar, 6-7 yıllık "Every Tick" verileri üzerinde çalışan, yani makul işleme ve bellek talepleri gerektiren oldukça karmaşık bir Uzmanla ilgilidir. Bu görevi üstlenen buluttaki aracıların yeterince belirtilmediğinden şüpheleniyordum - özellikle de Windows kutuları olacaklarını düşünürsek.

Bu yüzden OnInit() olay işleyicime aşağıdaki kod satırını koydum:

TERMINAL_MEMORY_PHYSICAL kullanmamın nedeni, diğer bellek seçeneklerinin: TERMINAL_MEMORY_TOTAL ve TERMINAL_MEMORY_AVAILABLE, size yalnızca ana bilgisayarın işlemcisinin toplam, kullanıcı modu sanal adres alanını sağladıklarından (yani, 32 bit işlemci için 4 GB veya 8 TB için) fazla kullanılmamasıdır. 64 bit işlemci). 8 TB belleğe sahip 64 bit makineler hayal edemiyorum - en azından henüz değil. :) TERMINAL_CPU_CORES düşündüğüm bir başkasıydı ama sonunda sadece bellek testi yapmaya karar verdim çünkü yeterli miktarda belleğe sahip herhangi bir kutunun diğer tüm önemli alanlarda düzgün bir şekilde belirtileceğini varsayıyordum .

Ve tahmin et ne oldu - artık sorun yok! Tüm optimizasyonlarım şimdi iyi çalışıyor. :)

Bu harika bir fikir gibi geliyor ve bu ipucu için minnettarım.

Ancak bununla ilgili 3 şey:

1) Yukarıda bahsettiğim gibi, "sonsuz" döngü sorunu bende de var, ancak bu başlıktan "sonsuz döngü"nün "bir olay on dakikadan uzun sürdü" için en iyi tahmin olduğunu anladığım için kabul ediyorum. kodum olabilir. Oldukça karmaşık göstergeler kullanıyorum ve (en azından öyle düşünüyorum) tanıtıcıları oluşturulurken tüm geçmişlerini hesapladıklarından, bu (yavaş bilgisayarlarda) on dakikadan fazla sürebilir.

2) Ancak! Genellikle bulutum 10-15 Dakika sonra çöktü. Ama dün gece, 8 saat boyunca mükemmel çalıştı. Kodu hiç değiştirmemiş olmama rağmen tek bir çökme yok. Garip!

3) Ve en önemlisi , çünkü yaklaşımınızla ilgili: Bir aracıyı hafızasına dayanarak reddettiğinizde, aracı (ve bunun için tüm bulut) çökmez, bunu anlıyorum. Ancak daha güçlü bir makinenin aynı parametre setini tekrar deneyeceğini sanmıyorum, bu nedenle temel olarak optimizasyon veri noktalarını kaybedersiniz, doğru muyum? Ödeyeceğimiz bedel bu mu diyeceksiniz?

İşten döndüğümde ajanlarımın hala çalışıp çalışmadığını merak edeceğim...

[Alain Verleyen]

cowil :
...

32G'den daha az ram'e sahip olanları reddettiğinizde , kaç temsilci kullanılabilir ?