Cadena privada, dos mineros geth en la misma máquina, el segundo minero arroja "pánico: ethash_full_new IO o error de memoria"

Estoy usando geth 1.4.18-stable-c72f5459 en Win7.

Estoy comenzando mis nodos con los siguientes parámetros:

geth.exe --datadir \work\eth\miner2 --nat none --nodiscover --networkid 1999 --mine --port 30304 --ipcpath miner2.ipc

Después de sincronizar con el otro nodo minero en la misma máquina, el segundo minero falla cuando comienza a minarse a sí mismo.

Mi mejor suposición hasta ahora es que las dos instancias tienen una colisión en AppData\Roaming\Ethash donde se almacena el DAG. Estaba buscando una opción para pasar una ubicación diferente a geth, pero parece que esta ruta está codificada.

panic: ethash_full_new IO or memory error

goroutine 387 [running]:
panic(0xbce660, 0xc0431f4b80)
        /usr/local/go/src/runtime/panic.go:500 +0x1af
github.com/ethereum/ethash.(*dag).generate.func1()
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:273 +0x695
sync.(*Once).Do(0xc0433b5860, 0xc043433bd0)
        /usr/local/go/src/sync/once.go:44 +0xe2
github.com/ethereum/ethash.(*dag).generate(0xc0433b5840)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:277 +0x53
github.com/ethereum/ethash.(*Full).getDAG(0xc0421de330, 0xa3, 0xc04343fc80)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:333 +0xa7
github.com/ethereum/ethash.(*Full).Search(0xc0421de330, 0x127d300, 0xc043438900, 0xc04349e240, 0x0, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:338 +0x7b
github.com/ethereum/go-ethereum/miner.(*CpuAgent).mine(0xc0433c3720, 0xc0433ac340, 0xc04349e240)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:121 +0x13a
created by github.com/ethereum/go-ethereum/miner.(*CpuAgent).update
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:90 +0x15a

Respuestas (4)

como has adivinado, el problema proviene del DAG.

Creo que las instancias de geth están generando dos DAG al mismo tiempo. para que pueda deshabilitarlo ejecutando geth --autodag=falseogeth makedag 0 /ethdata/

nota que --autodag=falseno funciona. Ejecute gethcon este parámetro y seguirá viendo el mensaje Automatic pregeneration of ethash DAG ON.

Tuve el mismo problema en mi máquina virtual remota de Windows Azure

lo resolvi por

1) Verificando el bit geth (32/64) Tenía un sistema de 64 bits y ejecuté geth de 32 bits y, por lo tanto, enfrenté este problema.

2) Comprobación del tamaño de almacenamiento Tenía una máquina virtual de Azure cuya memoria interna/tamaño de RAM era de solo 3,5 GB y que no es suficiente para generar y almacenar DAG.

--autodag=falseno funciona, porque tan pronto como se inicia el minero, se activa la pregeneración automática. Esto también sucede si llamo a miner.stopAutoDAG()través de la consola.

El problema parece ser que el segundo minero no puede leer el archivo DAG porque el primer minero lo tiene bloqueado. A través de shell, traté de llamar md5sumal archivo DAG mientras se ejecutaba el primer minero y obtuve md5sum: can't open 'full-R23-0000000000000000': Device or resource busy.

La única solución que funcionó para mí hasta ahora es iniciar el segundo minero con una cuenta de Windows diferente.

Después de ejecutar geth de 64 bits, funciona bien. Mi windows también es de 64 bits.