baris Is it possible to change bcrypt_rounds on an existing system which has already users and (hashed) passwords saved? (I am thinking of reducing the default of 12 to 10 as a test)
Can there be another OS config issue on the machine which can cause bcrypt to be that slow? I am thinking of the /dev/random vs. /dev/urandom scenario...
Thanks, much appreciated.
If bcrypt is causing that, then lowering the rounds value should also resolve that, at least for a test. Will post the results.
We did not modify the bcrypt_rounds parameter.
You mean the password hashing in bcrypt could drive a cpu% spike which the traffic management erroneously interprets as too high load?
Does that really sound realistic that the CPU is that busy with a single login and the following hardware - one VM for nodeBB and the same for mongoDB
Debian GNU/Linux 13 (trixie), Kernel 6.12.57
4 Cores x86_64 Architektur
8 GB RAM
Which way is less sensitive - tuning values up or down?
Currently they are set to 100 and 500 - and unfortunately the descriptions do not explain their meaning.
We do not have any traffic right now, nodeBB is runnning with 3 processes each < 1% CPU% and with traffic management enabled and the standard settings we get the 503 once after login.
With traffic management disabled the 503 does not happen.
Can I enable some more debugging/tracing to see why traffic management shuts down the session after login?
Checked for 12 --> 10 and works. Thanks!
baris Is it possible to change bcrypt_rounds on an existing system which has already users and (hashed) passwords saved? (I am thinking of reducing the default of 12 to 10 as a test)
Can there be another OS config issue on the machine which can cause bcrypt to be that slow? I am thinking of the /dev/random vs. /dev/urandom scenario...
Ay, after setting the first parameter to 500, the 503 does not occur anymore. Will dig into testing some more combinations tomorrow. Thanks 🙏
I did a quick test with setting the first parameter to 300, did a restart. Logout, login, and the 503 is still there.
Thanks, much appreciated. If bcrypt is causing that, then lowering the rounds value should also resolve that, at least for a test. Will post the results.
As said these are 100 500
We did not modify the bcrypt_rounds parameter. You mean the password hashing in bcrypt could drive a cpu% spike which the traffic management erroneously interprets as too high load?
Does that really sound realistic that the CPU is that busy with a single login and the following hardware - one VM for nodeBB and the same for mongoDB Debian GNU/Linux 13 (trixie), Kernel 6.12.57 4 Cores x86_64 Architektur 8 GB RAM
Which way is less sensitive - tuning values up or down? Currently they are set to 100 and 500 - and unfortunately the descriptions do not explain their meaning.
We do not have any traffic right now, nodeBB is runnning with 3 processes each < 1% CPU% and with traffic management enabled and the standard settings we get the 503 once after login. With traffic management disabled the 503 does not happen.
Can I enable some more debugging/tracing to see why traffic management shuts down the session after login?
I deactivated the traffic management and don't get a 503 anymore after login. But I don't want to completely leave that disabled, should I?
No, the process was started in that case by root, /opt/nodebb is owned by user nodebb I assume I need to start under user nodebb?