howdy folks, i've git cloned and build xmrrig miner on linux, is there some simple way for me to cap how much CPU it uses on the box?

I assume you checked --help. If there's nothing, then namespaces I guess.

`u=$(whoami); limit_pct=50; cg=xmrig_cpu; sudo cgcreate -t $u:$u -a $u:$u -g cpu:$cg; echo $(( $limit_pct / 100 * 100000 )) | sudo tee /sys/fs/cgroup/cpu/$cg/cpu.cfs_quota_us; cgexec --sticky -g cpu:$cg xmrig --algo rx/0 --url=stratum+tcp://donate.v2.xmrig.com:3333 -u '0000000000000000000000000000000000000000000000000000000000000000' --no-color`

change limit_pct to whatever you want, and install libcgroup

thanks cohcho

use --threads in case if you're ok with discrete values of limit

randomx is the default CPU algo at the moment?

There is no such thing as default algo I suppose

I don't know

comparator should yield strict ordering, since lookups use binary search

and can fail if not strictly ordered

hyc, my tests seemed to work with the less strict comparator. I just needed a way to do an append of exact duplicates and with the comparator returning -1 or 1 (not 0) the append works.

I can't see any other way to have duplicate KV items (MDB_DUPSORT needed for dup keys, MDB_APPEND needs sorted keys and MDB_APPENDDUP needs sorted data). Return 0 in a comparator and MDB_KEYEXIST occurs.

The 1/-1 comperator only occurs for data (mdb_set_dupsort), I'm still using strict comperators for keys.

jtgrassie : I would expect the -1 / 1 (not 0) comparator to fail on lookup though

although searching with MDB_SET_RANGE should still work

vtnerd: you mean lookup based on data value right? because i'm not doing that. it' all itterating based on key (which has strict comp).

e.g. MDB_SET and MDB_NEXT_DUP

ah if you're only iterating with NEXT_DUP then binary search is irrelevant, so you should be safe

cool, thanks for confirming

so yes, all calls are either MDB_SET->MDB_NEXT_DUP or MDB_FIRST->MDB_NEXT when itterating

then there are either appends (using MDB_APPENDDUP)

of overwriting current (MDB_CURRENT)

When I have a change that necessitates a db migrate, I'll revert the data comparators and migrate the data items to be unique.

jtgrassie: src/webui.c:start_web_ui() uses MHD_USE_SELECT_INTERNALLY, why not EPOLL?

It's what's recommended in the docs when using a single thread.

Api requests doesn't work as soon as many clients connected or many connect/disconnect occured.

I've changed to MHD_USE_EPOLL_INTERNAL_THREAD in order to have working api.

I recommend using a proxy (ala apache/nginx) for the api. That's what I use on the reference pool.

That then is set to cache responses.

I need realtime stats from monero-pool, don't see any need cache something here.

I'm talking about like 15 seconds cache, not a huge timeout.

Have you tested monero-pool with > 256 clients?

Api connection will just get fd > FD_SETSIZE and nothing will be able to use api.

caching will not help, unless it's using persistent socket

api or pool?

pool yes, over 10k tested

api uses apache front-end with cache paste.debian.net/1124412

I do think using epoll probably makes sense, I assume the docs just suggest MHD_USE_SELECT_INTERNALLY for portability.

either way, really should cache and proxy web api

and thats not the job of the pool.

Answer simple question: Is it possible that new connection to webui port will have socket fd always > FD_SETSIZE if number of active clients is > FD_SETSIZE + some_margin?

I don't probability of this event but it occurred here few times in a row.

don't know*

persistent connection to webui port established at the beginning works without any problem; then this issue probably doesn't matter outside of my environment

as I say, you really gotta use a proxy and cache for the webui. It's the most efficient way to allow pool to have lots of connections and the webui to not affect pool performance.

MHD_USE_EPOLL_LINUX_ONLY would definitely help on Linux, but not other platforms.

FD_SETSIZE isn't a valid constant anymore, should be using getdtblsize()

number of descriptors depends on nfiles ulimit anyway

BUGS section of `man 2 select` says about 1024 limit for select(); getdtablesize() equals to `ulimit -n` here which is really high 999999; the error i've never had 999999 active sockets so 1024 looks like a realistic limit at least for select().

s/the error//

and the webui defers to MHD (it doesn't even look at FD_SETSIZE). and if MHD is behind a caching proxy this is all redundant talk anyway.

microhttpd lib will fails somewhere inside it after each try to start select() with fd > FD_SETSIZE

your code will not report anything

the pool does look at FD_SETSIZE though, so yes, per hyc's point I sould change this at least.

no need to change for libevent listener since it uses the best available poller, epoll in my case

but webui is using select() since you've set it explicitely

w.r.t. MHD, I could feature test EPOLL and only use that if available for the webui, I just never bothered because I always intended webui to be behind a cacheing proxy.

It will be portable and fix my issue, good

ok I'll make the change, but please, use a proxy cache, they are better suited for the webui needs.

I need api mostly to monitor what's going on with workers

It isn't exposed to others

Also i've added few methods to get worker stats

my environment is too dynamic to have caching timeout > 1 second

You speak of lots of changes you are making. Can you show/share?

They are ugly but works

I'll after some testing