![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Optimizasyon sırasında geçişlerin sonuçları ve tek geçiş eşleşmiyor (servis masası - #329165 + danışman aynı yerde)
Optimizasyon sırasında geçişlerin sonuçları ve tek geçiş eşleşmiyor (servis masası - #329165 + danışman aynı yerde)
619 yap ? Aynı sorun kendini göstermeye başladı. Ama her zaman değil. Hatta sonuçların aynı olduğu, yani yeni bir optimizasyon gerçekleştirmedikleri bile oluyor, ancak bir nedenden dolayı sonuçlar test ederken zaten farklı. Örneğin, grafikteki toplam kâr, listedekinden farklıdır. Bir süre sonra her şey geri yüklenir. 619 oluşturmadan önce, bunu hiç fark etmemiştim.
607 tane daha oluşturun (henüz yeni FIBO'ya güncellenmedi). Belki de sorun çoklu para biriminde ve zamanlayıcıdadır (OnTick() kullanılmıyor), ama emin değilim.
Strateji test cihazı ile son derlemede bir şeyler ters gitti. Aniden (oldukça "aniden" değil, ancak 619'u oluşturmak için güncelleme yaptıktan sonra) EA neredeyse test edilmeyi bıraktı (istek #329165 ile aynı) - bellek ölçülemez bir şekilde tüketilmeye başladı ("Her tik" modu 5 yıl boyunca):
Son sütun "VM boyutu" dur. Gördüğünüz gibi, 4 çekirdek + 4 "uzak" yerel aracım var (her zaman iyi çalıştı).
Aynı zamanda sistem çok fena yavaşlamaya başlıyor (evet, PageFile için 4GB RAM + 16GB verdim) ve optimizasyon hızı sonsuza kadar gidiyor. Gördüğünüz gibi, işlemci süresi pratikte meşgul değil.
Günlükteki hatalar şunlardır:
Bu görünüşe göre hafıza eksikliğinden kaynaklanıyor.
"Dur" a basıyorum - hafıza hemen serbest bırakılmıyor. 5 dakika sonra, yerel ajanlar ortadan kayboldu, iki dakika daha sonra uzaktakilerin hafızası serbest bırakıldı:
Bir aracının neden hala askıda kalacak 100 MB'den fazla kaldığı açık değil (işlemci süresi kullanılmadığı için Bulut'un bunu aldığına inanmıyorum).
"Uzak" yerel ajanları devre dışı bırakıyorum. Hiçbir şey değişmez (sistem frenleri ve hatalar).
Bence günahkar bir şey, danışmanımda hatalar var. Bu nedenle, test için 2007.09.01'den 2012.03.26'ya kadar standart ExpertMACD, EURUSD, h12'yi başlattım.
Ve ... aynı resim - frenler, çılgın bellek tüketimi (göstergeler ilk resimdekiyle neredeyse aynı) + "uzman başlatılamıyor".
Her iki durumda da, bazı pasajlar hala gerçekleşmeyi başarıyor.
Günlük eklendi.
Çok ilginç satırlar:
vb. USDNOK ile - EA kodumda bir SGDJPY sembolü yanıp söndü - neden USDSGD yerine USDNOK (USDJPY günlükler tarafından başarıyla yüklendi) indiriliyor?
Herhangi bir şey varsa, sunucu FIBOGroup-MT5-sunucudur.
PS Önceki yapılarda bu tür sorunları gözlemlemedim.
PPS Kim tembel değil - lütfen tüm keneler için son 5 yıl için standart ExpertMACD'nin optimizasyonunu kontrol edin.
Strateji test cihazı ile son derlemede bir şeyler ters gitti. Aniden (oldukça "aniden" değil, ancak 619'u oluşturmaya güncellemeden sonra) EA neredeyse test edilmeyi bıraktı (istek #329165 ile aynı) - bellek ölçülemez bir şekilde tüketilmeye başladı ("5 yıl boyunca her tik" modu):
Son sütun "VM boyutu" dur. Gördüğünüz gibi, 4 çekirdek + 4 "uzak" yerel aracım var (her zaman iyi çalıştı).Aynı zamanda sistem çok fena yavaşlamaya başlıyor (evet, PageFile için 4GB RAM + 16GB verdim) ve optimizasyon hızı sonsuza kadar gidiyor. Gördüğünüz gibi, işlemci süresi pratikte meşgul değil.
Çekirdek sayısından daha fazla aracı çalıştırmanız önerilmez. Çok sayıda aracıdan dolayı hız doğrusal olmayan bir şekilde düşer ve kaynak maliyetleri artar. Özellikle yalnızca 4 Gb bellek olduğunda ve aracılar gigabaytları ve daha fazlasını tükettiğinde.
Uzak aracıları, ana terminal çalışmanızı yaptığınız bilgisayara kurmayın.
Günlükteki hatalar şunlardır:
Bu görünüşe göre hafıza eksikliğinden kaynaklanıyor.
"Dur" a basıyorum - hafıza hemen serbest bırakılmıyor. 5 dakika sonra, yerel ajanlar ortadan kayboldu, iki dakika daha sonra uzaktakilerin hafızası serbest bırakıldı:
Evet, bellek (önbellekler) yaklaşık 5 dakika sonra serbest bırakılır. Bir sonraki lansmanda, son lansmanda kullanılan aynı verileri çoğu zaman ısıtmak için zaman kaybetmemek için özel olarak tutulurlar.
En son derlemede, tekrarlanan geçişleri hızlandırmak için önbelleklerin çalışma şeklini değiştirdik ve bu da önbelleklerin artmasına neden oldu.
Bir aracının neden hala askıda kalacak 100 MB'den fazla kaldığı açık değil (işlemci süresi kullanılmadığı için Bulut'un bunu aldığına inanmıyorum).
"Uzak" yerel ajanları devre dışı bırakıyorum. Hiçbir şey değişmez (sistem frenleri ve hatalar).
Bence günahkar bir şey, danışmanımda hatalar var. Bu nedenle, test için 2007.09.01'den 2012.03.26'ya kadar standart ExpertMACD, EURUSD, h12'yi başlattım.
En son sürüme yükselttikten sonra EA'yı yeniden derlediniz mi?
Sizin durumunuzda sorun, sürekli değiştirme ve bellek eksikliği nedeniyle frenlerde. İpucu: Gereksiz uzak aracıları devre dışı bırakın.
Çekirdek sayısından daha fazla aracı çalıştırmanız önerilmez. Çok sayıda aracıdan dolayı hız doğrusal olmayan bir şekilde düşer ve kaynak maliyetleri artar. Özellikle yalnızca 4 Gb bellek olduğunda ve aracılar gigabaytları ve daha fazlasını tükettiğinde.
Uzak aracıları, ana terminal çalışmanızı yaptığınız bilgisayara kurmayın.
En son sürüme yükselttikten sonra EA'yı yeniden derlediniz mi?
Sizin durumunuzda sorun, sürekli değiştirme ve bellek eksikliği nedeniyle frenlerde.
İpucu: Gereksiz uzak aracıları devre dışı bırakın.
Devre dışı bırakıldı, optimizasyon için ExpertMACD'yi başlattı ve:
Ve şimdi biri hariç tüm aracıları (yerel olanlar dahil) devre dışı bıraktım:
ve şimdi ne olacak? 4 GB bir temsilci için yeterli değil mi? (Mem Kullanımı 350MB olmasına rağmen, VM Size = 1.24GB). Peki ya 4GB'ı bile olmayanlar?
Belki kontrol et? Oynatma adımları - önceki gönderide
Bulut istatistiklerinde görebilirsiniz - 4 nedir, 8 ajan nedir - PR hala 150-190 bölgesinde (görünüşe göre tarayıcı çekirdeğine düşen bir / iki hariç) Devre dışı bırakılmış uzak ajanlar ... Uzmanlar yeniden derlendi . Normal ExpertMACD'yi bile yeniden derledim.
Devre dışı bırakıldı, optimizasyon için ExpertMACD'yi başlattı ve:
Ve şimdi biri hariç tüm aracıları (yerel olanlar dahil) devre dışı bıraktım:
ve şimdi ne olacak? 4 GB bir temsilci için yeterli değil mi? (Mem Kullanımı 350MB olmasına rağmen, VM Size = 1.24GB).
Belki kontrol et? Oynatma adımları - önceki gönderide
Hataları görmek için uzmanın günlüğüne bakmak yeterliydi:
Doğru zaman dilimini ve doğru ayarları seçin. Varsayılan limitleri kullanırsanız, birçok yanlış parametre üretebilirsiniz.
Hataları görmek için uzmanın günlüğüne bakmak yeterliydi:
Doğru zaman dilimini ve doğru ayarları seçin. Varsayılan limitleri kullanırsanız, birçok yanlış parametre üretebilirsiniz.
Evet, gerçekten de sorun varsayılan parametrelerdeydi. Değiştirildi - her şey normal olarak test edildi. Danışmanıma döndüm - öyle görünüyor ki "uçuş da normal".
Toplamda, daha önce çekirdek başına iki ajanın varlığına elveda denildiyse, şimdi kesinlikle öyle değil.
Toplam2. Yanılmışım, harcanan zaman için üzgünüm (ama servis masası - # 329165 henüz çözemedi)
Anlayalım.
Bir şey ertelendi. Bu arada, neler olduğunu anladım.
1) Kodun yeniden düzenlenmesi sırasında, değişkenin değerinin açık atamasını kaybettim ve bazen (oldukça rastgele) açılan pozisyonun hacmi için rastgele sonuçlar aldım. Bu hatayı düzelttikten sonra sonucun değişmediğini gördüm - test sonuçları optimizasyonla eşleşmiyor. Bir tef ile çeşitli kayıt ve dans sayesinde, sorunun oldukça eski olduğu ortaya çıktı:
2) 2011 şampiyonasının başlamasından önce, testçinin hafta sonları işlem yaptığını bildirmiştim. Renat kontrol etmeye söz verdi. Ama sorun hala devam ediyor. Tamamen tesadüfen, bir gün olan 2007.09.01 test döneminin başlangıcını seçtim. Bu nedenle, optimize edici o gün bir anlaşma yapmaz, ancak test eden yapar. Veya daha doğrusu, optimize edicide çıktıda OrderSend'e ulaşmaz, ancak test cihazında yapar. Uzman Danışmanımın mantığına dayanarak, optimizasyon aralığının başlangıcı izin gününe düşerse, ilk zamanlayıcı tetiklemesinde ACCOUNT_EQUITY = 0!!! Ve test cihazında ACCOUNT_EQUITY = ACCOUNT_BALANCE (ilk depozitoda belirlediğimiz şey). Optimizasyon aralığının başlangıcı bir iş gününe denk geliyorsa, optimize edici ve test edicinin davranışı aynıdır.
Toplamda, iki hatanız var:
1) Test cihazı, olmaması gereken bir hafta sonu bir anlaşma açmanıza izin verir (ve bunun benim hatam olduğunu söyleme - hatalarımı düzelteceğim ve test cihazının hatası yarım yıldan fazla bir süredir asılı duruyor);
2) Zamanlayıcının ilk tetiklenmesinde, dönemin başlangıcı izin gününe denk gelirse, ACCOUNT_EQUITY = 0 ve test cihazında ACCOUNT_EQUITY = ACCOUNT_BALANCE. Bunu tek bir forma getirmek gerekir (elbette daha iyi, ilk hata düzeltilerek ACCOUNT_EQUITY = ACCOUNT_BALANCE'a).
Servis masasında istek üzerine #329165 testler için bir uzman ekleyeceğim.