P2Pool 4.18 оптимізує Stratum і виправляє ініціалізацію на системах із 256+ потоками

Реліз зменшує алокації в гарячих шляхах, надсилає jobs малими пакетами й краще масштабується на великих CPU-системах.

Це не чергова обіцянка «більшого хешрейту», а конкретна зміна у відкритому проєкті, яку можна перевірити за кодом, релізом і журналом змін. Редакція розібрала, що саме відбулося, кому це важливо і де закінчуються підтверджені факти.

Що сталося

P2Pool 4.18 включає помітний набір інфраструктурних змін. Ініціалізацію dataset виправлено для систем із 256 і більше потоками, у TCP send path та StratumServer прибрано частину алокацій пам’яті, а нові jobs тепер відправляються невеликими пакетами, щоб не блокувати основний цикл подій. Додано паралельні batch-алгоритми для crypto cache, явну перевірку максимальної кількості uncles і оновлення BoringSSL. Також локальні або приватні адреси Monero node більше не спрямовуються через SOCKS5-проксі.

Головне за хвилину

• Ключова зміна. P2Pool 4.18 включає помітний набір інфраструктурних змін.
• Що було раніше. Ініціалізацію dataset виправлено для систем із 256 і більше потоками, у TCP send path та StratumServer прибрано частину алокацій пам’яті, а нові jobs тепер відправляються невеликими пакетами, щоб не блокувати основний цикл подій.
• Практичний крок. Операторам великих вузлів варто окремо виміряти час запуску, пікову пам’ять і latency видачі jobs під навантаженням.

Чому ця новина важлива

Майнінгові системи працюють безперервно, тому навіть невелика помилка у протоколі, пам’яті, живленні або телеметрії з часом перетворюється на простої, неправильний облік чи зайве споживання. Тут важливий не рекламний відсоток, а передбачуваність: оператор має розуміти, що змінилося, як це перевірити і як повернутися до попередньої версії.

Коротко: Реліз зменшує алокації в гарячих шляхах, надсилає jobs малими пакетами й краще масштабується на великих CPU-системах. Це технічна новина про продукт і його розвиток, а не прогноз курсу чи обіцянка окупності обладнання.

Що варто зробити користувачам

Операторам великих вузлів варто окремо виміряти час запуску, пікову пам’ять і latency видачі jobs під навантаженням. Зміна обходу SOCKS5 для LAN-вузлів логічна, але потребує перевірки маршрутів і firewall rules. Оновлення залежностей саме по собі не замінює контроль supply chain: збірку краще виконувати з зафіксованого тега, перевіряти підпис або commit hash і не змішувати бінарники з різних джерел.

Перед зміною робочої конфігурації варто зробити резервну копію, зафіксувати поточні версії та підготувати шлях відкату. Код і бінарні файли потрібно брати з офіційного репозиторію, перевіряючи тег або commit. Короткий успішний тест ще не доводить стабільність під тривалим навантаженням.

Джерело й умови використання

Автори оригінального проєкту: SChernykh та учасники P2Pool. Матеріал редакційно переказано й адаптовано українською без копіювання великих фрагментів. Ліцензія першоджерела: GNU GPL v3.0. Якщо вона містить ShareAlike або strongly reciprocal, похідні ліцензовані файли поширюються на тих самих умовах.