Ana içeriğe geç
Tüm KoleksiyonlarEOS Support Medyası
EOS Node Operatör Toplantısı 23 Kasım 2022 - Yüksek RAM kullanımı
EOS Node Operatör Toplantısı 23 Kasım 2022 - Yüksek RAM kullanımı

6 Aralık 2022'de yayınlandı

Dario Cesaro avatar
Yazar: Dario Cesaro
Bir aydan uzun süre önce güncellendi

Yazar: Markus Hinrichs

Editör: Randall Roland

Çeviri: Taha

Toplantıda alınan kararlar üzerine Leap 3.2 yayınlandı. Ayrıca, Devlet Veritabanının asıl sorunu olan yüksek RAM kullanımı tartışıldı. Potansiyel uzun ve kısa vadeli düzeltmeler ve takaslar araştırıldı.

Ayrıca, toplantının sonunda ENF'den Net Plugin Enhancements ayrıntılarının kısa bir özeti verildi: Leap 4.0'ın Prometheus Exporter'ı kara kutu nodEOS için istatistikler içeriyor . Toplantıda 13 katılımcı vardı.

Yazılım geliştirme, haftalık EOS Node Operatörü Toplantısı oturumlarındaki ana tartışma konusudur. EOS geliştirme süreci hakkında daha fazla bilgi edinmek isteyen geliştiriciler, Blok Yapımcıları, blockchain mühendisleri ve topluluk üyelerinin tümü, sağladığı bilgilerden yararlanır.

Bir ekosistem, sıklıkla paylaşarak ve etkileşim kurarak sağlıklı ve doğal bir şekilde büyüyebilir. EOS Network Foundation, ilerleme durumu hakkında BP'lerden ve geliştiricilerden olumlu yorumlar aldı. EOS Topluluğu, artık sesinin takdir edildiğinin ve duyulduğunun bilincindedir. Son olarak, topluluk endişelerine yanıtlar veriliyor.

Stephen Diesel'den (ENF, Leap Üretim Müdürü) Antelope Leap Güncellemelerinin Özeti yakında

GÜNCELLEMELER

YAYINLAMA ZAMANI

Leap 3.2 son sürümü

Github'da yayınlandı

Sistem sözleşmesi güncellemeleri

yakında

DUNE'un piyasaya sürülmesi

Aralık 2022

Bu toplantının başında Stephen, Leap 3.2'nin Github'da yayınlandığını, ancak bunun bir fikir birliği yükseltmesi olmadığını ve bu nedenle isteğe bağlı olduğunu duyurdu.

Brian Hazzard, yükseltmeyle ilgili tüm sorular için çeşitli kanallarda hazır bulunmayı kabul etti. Son toplantı harika fikirleri topladığından ve birikim için bazı yeni potansiyel özellikleri tanımladığından, önümüzdeki hafta Net Plugin Enhancements belgesinin bir güncellemesi yapılacak.

Veritabanı Durumu Değiştirildi: Geçmişi depolamak için çok fazla RAM kullanıldı

EOSUSA'dan Michael toplantıya katılamadı, ancak bu toplantının konusunu önerdi: Durum Veritabanı Kırpma. Katılımcılar, asıl sorunun çok fazla RAM kullanılması olduğu konusunda hemfikirdi. Per Stephen, RAM sorununu araştırmak için araştırma yapmak amacıyla bir RFP taslağı hazırlanmaktadır.

Takas Performansı ve RAM Boyutu.

Ana soru Kevin Heifner tarafından soruldu: "RAM boyutu için ne kadar performanstan ödün vermeye razısınız? Verileri RAM'e yüklemek için (bir ısıtma bloğu gibi) 1 blok üretim döngüsünden ödün vermeye istekli misiniz?" Ancak, bu çözümde yüksek bir spam riski vardır.

RAM için asla karşılanamayacak kadar büyük bir talep var. Şu anda WAX durum veritabanını sorunsuz çalıştırmak için 128 GB RAM gerekiyor. Sorun, normal cihazların daha fazla RAM için yeterli alana sahip olmamasıdır. Güçlü CPU'lara ve bol miktarda RAM'e sahip cihazları bulmak zordur. Belki de grafik tasarımcı/animatör cihazları gelecekteki gereksinimleri karşılayabilir.

Tanımlanmış kısa ve uzun vadeli fırsatlar (alıntı)

Kısa vadeli fırsatlar

  • Bu konuyu araştırmak için Antelope koalisyonu tarafından bir RFP taslağı hazırlanmaktadır.

  • Yığın modunun başlatılmasını ve kapanmasını daha hızlı yapın

  • Tmpf'leri kutunun dışında yapmak için bir fırsat var mı?

  • Hesap sorgularını devre dışı bırakmak, RAM'de tasarruf sağlayabilir (ağ operatörü yapılandırması için fırsat)

  • Hesap sorgularını diskte depolayın (14 milyon WAX hesabı 4 GB tasarrufta bulunulabilir, muhtemelen buna değmez)

Uzun vadeli fırsatlar

  • Akıllı sözleşmeler, RAM ve Disk depolamayı belirtmek için teşvik edilebilir mi?

  • Donanım satıcılarının yüksek miktarda RAM içeren çok hızlı CPU çekirdekleri sunmaya başlaması gerekiyor

P2P İyileştirmeleri (Net Eklentisi) (Brain Hazzard tarafından)

Brian Hazzard, aşağıdaki endişelere hızlı bir şekilde değindi ve ev sahibi Daniel Keyes'in yakın zamanda tartışılan Net Plugin'in geliştirilmesine yönelik belirli önerilerin kısa bir özetini verip veremeyeceğini sorduktan sonra bunları bir sonraki toplantıda daha ayrıntılı olarak sunmayı teklif etti.

  1. Geçişteki bloklar için oluşan daha hafif doğrulamalar yapma olasılığı olacaktır. Bu, zamandan tasarruf sağlayabilir ve geçişi daha hızlı hale getirebilir

  2. Bir bloğun dolu olup olmadığını (yerleşik CPU süresi açısından) yayınlıyorsa ve bir sonraki blokta başlıyorsa kodlamak mümkün olacaktır.

  3. Gecikmeyi optimize etmek için eşleri otomatik olarak yapılandırma (BP'ler şu anda bunu manuel olarak yapıyor).

    1. program için optimize et (Hangi BP önce, hangisi sonra gelir?)

    2. gecikme açısından optimize et

Gelecek Haftanın Gündemi

EOS Nation'dan Matthew tarafından önerilen bir sonraki Leap 4.0'da prometheus ihracatçısına hangi verilerin dahil edilmesi gerektiğine dair bir müzakere:

  • nodeEOS bir kara kutu gibidir, birçok ağ operatörünün içinde neler olduğu hakkında hiçbir fikri yoktur. Bununla ilgili bazı istatistikler verilmesi isteniyor.

  • Ağ toplantısının katılımcıları, bir sonraki toplantıda prometheus için istekleri konuşulacak.


Toplantının katılımcıları (13):

  • Randall Roland | EOSsupport.io

  • Dario | EOSsupport.io

  • Kevin Heifner | OCI

  • Matt Witherspoon | ENF

  • Brian Hazzard

  • Jannis - Rakeden (Jannis)

  • Max Cho | KOREOS

  • Daniel Keyes | EOS Nation

  • Stephen Diesel | ENF

  • Matthew Darwin | EOS Nation

  • Corvin Meyer auf der Heide | liquiid.io

  • Patrick Burns | Aloha EOS

  • Ross Dold | EOSphere


Kaynaklar & Referanslar

Bu cevap sorunuzu yanıtladı mı?