connection.host undefined

[cazala]

connection.host undefined

[QuantumLeaper]

Nofile ulimit is set to 65k, script crashes around 6k files so it's not that. Worked on the previous version no problems asides from the pool itself blowing up from all of the individual connections lol

[procloud]

what version are you running?

[QuantumLeaper]

V1.4.4

[procloud]

i did read that other proxies, like xmrig-proxy can take about 100k connections and reduce them to about 350 on the pool side (on a t1.micro instance). so there may be a limit as to how many miners can be piped through one tcp connection to the pool before things start to break...

[QuantumLeaper]

Tried it on a a websocket proxy that only had a few hundred connections, after about 30 minutes the same error occurs. When I cutover one with 12k+ connections by the time it hits 2-4k concurrent connections which is almost immediately, it throws the same error and dies. Not too sure what it is haha. I think somehow on connectiondestroy may be setting an active connection to null every once in a while, causing the script to crash and drop all connections

[procloud]

try increasing the ulimit on the OS?

[procloud]

https://github.com/xmrig/xmrig-proxy/wiki/Ubuntu-setup

[cazala]

mm yea that's because the connection was destroyed at the time the message from the miner was processed (because it was queued) that can be fixed with a simple if, i ll do it and publish a patch

[cazala]

fixed in v1.4.6

[cazala]

thank you for reporting! hopefully this will get more stable soon

[QuantumLeaper]

Awesome, I did something like that and then got an error about message being empty, so I also commented out the logger for reporting invalid messages from client for now. I will give it another test here in a day or so. One other thing I noticed is once it reaches around 4k-7k connections on a singular KVM with 4vcpu, it establishes a connection quickly, but responses are slow or sometimes nonexistant when it comes to receiving a jobid or sending a jobid and awaiting confirmation from the pool. However, the CPU, memory, and Disk IO are all within very reasonable limits. I think the queue might be a bit of a bottleneck at high workload instances. Using the python script, it can handle around 22k concurrent connections under 2.5 load pretty well and connections/jobid's are still instant. I'd prefer switching to this as soon as possible though :D I'll try to submit as much feedback as I can :)

Also, a quick note I thought I'd add for anybody using nodejs-pool, you'll have to edit lib/pool.js and configure the max_packet_size to a higher rate, which is currently set to 10K (if you're running thousands of connections per site_id) Unfortunately that means this won't work quite as-well on public pools

[cazala]

I deleted some conditions that were causing jobs from miner not being sent to the pool and jobs from pool not being sent to the miners. Also I deleted some references to undefined variables (old code) that was throwing in certain corner cases. I published this under version v1.4.7.