Geliştiricilere soru - optimizasyon sırasında tüm bilgi işlem çekirdeklerinin kullanımı - sayfa 8
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
İlginç bir yaklaşım.
Spesifiklere bağlı olarak, bu soruna birkaç çözüm olabilir.
tüm parametreler, zaten var olanlar ve görünebilecek olanlar, parametre setinde (kromozom veya diğer eşdeğer) kesin olarak tanımlanmış bir yere sahipse, o zaman hiçbir sorun yoktur.
her parametrenin belirli konumu önceden belirlenemezse, parametreleri yalnızca birbirleriyle kesinlikle birleştirilebilecek türlere bölmek gerekir (o zaman parametrenin nerede olduğu önemli değildir) - AO'nun değiştirilmesi gerekli olmak.
sorunu çözmek için başka seçenekler de var, ancak her durumda, standart olanın üzerinde bir eklenti olan özel bir AO'ya ihtiyacınız olacak.
bellek aşırı yüklemesi hakkında bilgi doğrulandı .... garip olsa da, kimse takası iptal etmedi, yine geliştiricilerin bunu hesaba katması gerektiğini düşünüyorum
Sorunu nasıl çözdüğünüzü aboneliğinizi iptal edin. Senin için endişeleniyoruz.
Bir aracı için ne kadar minimum bellek gereklidir (herkes eşit şekilde yüklenmeye başlayana kadar etkinleştirilenlerin sayısını azalttınız mı?)
Sayfa dosyasını artırdınız mı? Bu durumda, fiziksel bellek sürekli olarak değiştirilir, güçlü bir yavaşlama mümkündür, toplam optimizasyon süresi minimum olduğunda bu kadar çok sayıda çekirdek bulmak gerekir.
Sorunu nasıl çözdüğünüzü aboneliğinizi iptal edin. Senin için endişeleniyoruz.
Bir aracı için ne kadar minimum bellek gereklidir (herkes eşit şekilde yüklenmeye başlayana kadar etkinleştirilenlerin sayısını azalttınız mı?)
Sayfa dosyasını artırdınız mı? Bu durumda, fiziksel bellek sürekli olarak değiştirilir, güçlü bir yavaşlama mümkündür, toplam optimizasyon süresi minimum olduğunda bu kadar çok sayıda çekirdek bulmak gerekir.
Her şey kene kullanımına, tarihin derinliğine, enstrüman sayısına bağlıdır. Sadece görev yöneticisine bakın, orada her şey görünür, işletim sistemi için tüm RAM eksi 1-2 GB hacminin bir aracı tarafından kullanılan hacme bölünmesi. Herkes bireysel olarak her şeye sahiptir.
Geliştiriciler, alıntılar ve muhtemelen göstergeler için bir RAM alanı kullanılırsa durumu gerçekten iyileştirebilir.Her şey kene kullanımına, tarihin derinliğine, enstrüman sayısına bağlıdır. Sadece görev yöneticisine bakın, orada her şey görünür, işletim sistemi için tüm RAM eksi 1-2 GB hacminin bir aracı tarafından kullanılan hacme bölünmesi. Herkes bireysel olarak her şeye sahiptir.
Geliştiriciler, alıntılar ve muhtemelen göstergeler için bir RAM alanı kullanılırsa durumu gerçekten iyileştirebilir.bana açıklıyor musun? Bu sorunu bir kişiye açıkladım ve şimdi sonuçla ilgileniyorum. Geri bildirim yok.
Ve zaten terminal tarafından belleğin verimsiz kullanımını birçok kez tartıştık ve MQ, her bir aracı için onayların ve geçici dosyaların geçmişini çoğaltarak ve her bir onay optimizasyonundan önce bunların uzun bir süre boyunca oluşturulmasıyla durumu değiştirmek için birkaç kez söz verdi. Şahsen, aracıların neredeyse yarısını devre dışı bırakmam ve birkaç yıl içinde optimizasyonu işaretlemem gerekiyor. 8 GB ve 8 aracım var. Ama şimdilik elimizdekileri kullanıyoruz ve ya bellek boyutunu artırabiliriz ya da aracıları devre dışı bırakabiliriz.
bana açıklıyor musun? Bu sorunu bir kişiye açıkladım ve şimdi sonuçla ilgileniyorum. Geri bildirim yok.
Ve zaten terminal tarafından belleğin verimsiz kullanımını birçok kez tartıştık ve MQ, her bir aracı için onayların ve geçici dosyaların geçmişini çoğaltarak ve her bir onay optimizasyonundan önce bunların uzun bir süre boyunca oluşturulmasıyla durumu değiştirmek için birkaç kez söz verdi. Şahsen, aracıların neredeyse yarısını devre dışı bırakmam ve birkaç yıl içinde optimizasyonu işaretlemem gerekiyor. 8 GB ve 8 aracım var. Ama şimdilik elimizdekileri kullanıyoruz ve ya bellek boyutunu artırabiliriz ya da aracıları devre dışı bırakabiliriz.
> Sorunu nasıl çözdüğünüzü aboneliğinizi iptal edin. Senin için endişeleniyoruz.
> Bu sorunu bir kişiye açıkladım ve şimdi sonucu merak ediyorum. Geri bildirim yok.
Üzgünüm, çalıştım, zaman yoktu.
Danışmanın optimizasyonu yapıldı. Optimize edicinin çalışmaya başlaması için bazı "önemsiz" kısımlar kaldırıldı (özellikle OpenCL ve SQLite ile ilgili her şey). Şimdi hafıza taşması yok. AMA ... bu elbette bir çözüm değil.
Başka bir bilgisayarda donmamak için bazı çekirdekleri devre dışı bırakmak zorunda kaldım ... örneğin, 3950X (16 çekirdek / 32 iş parçacığı) ve 32 GB'deki bir sistem - tüm iş parçacıklarını kullanırken - sadece asılı kaldı ve hepsi bu . Üstelik, işlemi görev yöneticisi aracılığıyla teslim edene kadar askıda kalan ve asılan ajanlardı .... Bazı çekirdekleri kapattım, bir yanlış hesaplama oldu. Geliştiricilerin sorunu netleştirmek için bir şeyler yapması gerektiğini düşünüyorum. Optimize edicinin hesaplamak için tam olarak on bir gigabayt belleğe ihtiyacı varsa, bu açıkça bir uyarı gibi bir şeyle yazılmalıdır. Yine de bir takası hatırlatacağım. Yüklü Xmeters'im var ... böylece bellek yükünü görsel olarak görev çubuğunda görebiliyorum.
Özellikle AMD CPU ile bağlantılı başka bir aksaklık olduğunu düşünüyorum ve bu daha önce olmadı - danışman aynı olmasına rağmen. Belirtiler aşağıdaki gibidir - sadece 5 çekirdek dahil .... ve yanlış hesaplama kilitleniyor ... ve bu kesinlikle hafıza değil, çünkü aynı danışman 16 iş parçacığını sorunsuz yüklerken dikkate aldı ve bu sorun bir şekilde yüzüyor ya da vardır veya yoktur. Testi optimize edicide değil de çalıştırırsanız, normal olarak yürütülür. Bunu birçok kez fark ettiniz. Temel olarak, bunu çözmeniz gerekiyor.
Ağ ajanlarındaki frenlerle ilgili olarak - işler hala orada. "Bir çekirdek - bir görev" - geliştiricilerin anlayışına erişilemez. Daha önce olduğu gibi, 10 çekirdek her birine 30 görev dağıtılacak ve 30 ağ aracısı boşta. Bir şey hakkında uzun süre düşünerek görevler verir. Genel olarak, frenler sağlamdır.
ve evet unuttum: Katılımınız, tüm olası yardımlarınız ve tavsiyeleriniz için hepinize teşekkür ederim.Renat Fatkhullin'e
Yine de konuyu tekrar gündeme getirmek ve özellikle Renat Fatkhullin'e bir soru sormak istiyorum.
1. Performans açısından tamamen farklı birkaç sunucudan oluşan yerel bir grupta optimizasyon yapıyorum ve optimizasyon sırasında tam olarak CPU'ların farklı performansa sahip olmasından kaynaklanan korkunç gecikmeler gördüm. Diyelim ki Xeon E5-2620 v2 (2.1 GHz), Xeon E5-2620 0 (2.00 GHz), i7-3820 (3.6 GHz), Xeon E3-1245 (3.7 GHz), Ryzen 7 2700 .Ryzen 9 3900X CPU'lu sunucular var. , Ryzen 9 3950X. Mevcut algoritma şu şekilde çalışır: bir dizi görev oluşturur, bu görev grubunu mevcut her bir çekirdeğe eşit olarak böler. Şimdi, Xeon E5-2620 0 (2.00 GHz) ve Xeon E5-2620 v2 (2.1 GHz) düşük hızlı CPU'larımız olduğunu düşünürsek, çiftliğin görevlerini hesapladığı ve boşta olduğu ve bu iki CPU'nun da olmadığı ortaya çıkıyor. görevlerin yarısını bile hesapladı. Böylece tüm çiftlik aptalca duruyor. Bu, CPU'ların farklı hızları olduğu ve görevler gruplar halinde dağıtıldığı sürece gerçekleşir ve olmaya devam edecektir. Deneyimler, ağ gecikmelerinin hiç önemli olmadığını ve ihmal edilebilir düzeyde olduğunu göstermektedir. Görev dağıtım algoritmasını yeniden yapmak mümkün mü: mevcut her çekirdeğe birkaç görev dağıtmayın, ancak " serbest bırakılan her çekirdeğe - mevcut nesil paketten bir görev verin"?
2. Test sonuçlarını her 10 dakikada bir xml dosyasına kaydetmeyi eklemek mümkün mü .... ve son kaydetme konumundan başlayarak?
Test edicinin ve optimize edicinin tamamen yeniden yazılmasıyla ilgileniyoruz.
Birikmiş sorunları kökten yeniden yapacağız ve düzelteceğiz.
Test edicinin ve optimize edicinin tamamen yeniden yazılmasıyla ilgileniyoruz.
Birikmiş sorunları kökten yeniden yapacağız ve düzelteceğiz.
Olur mu:
1. Aracının biriktirme listesine daha hızlı tepki, izin verildiğinde, aracıdan yanıt gelmediğinde, paketlerin verilmesi dakikalarca kesintiye uğrar ve paketler yeniden dağıtılır.
2. Uzak bir makinedeki tüm aracılar için tek bir veri örneğinde indirme olasılığı uygulanıyor mu?
3. Aracıya bağlantı, optimizasyon için gerekli tüm verileri (dosyaları) indirmeden başarısız olduğunda, büyük miktarda veri aktarma sorunu çözülecek mi?
İşte beni endişelendiren bir şey daha var....
Diyelim ki optimizasyon devam ediyor ve o anda aracının meta tüccarı güncelleniyor .... aynı zamanda, aracının bir görevi vardı (daha doğrusu, bir dizi görev), kaybolacak mı yoksa yeniden hesaplanacak mı? ?