Thanks for every one! This issue seems to disappear after the change in config. Our site is more stable than ever before in the last week with a rather short response time during the whole week. Thanks again and welcome to have a visit. Advices on the site is always welcomed.

@julian This is the peak today(about 75% of history peak). Total: 13965 (kernel 0) TCP: 46823 (estab 13808, closed 32768, orphaned 231, synrecv 0, timewait 32768/0), ports 0 Transport Total IP IPv6 * 0 - - RAW 0 0 0 UDP 0 0 0 TCP 14055 10241 3814 INET 14055 10241 3814 FRAG 0 0 0 [image: 0I8JTTa.png] Actually, the performance today is better and fast after I applied a change in config: "socket.io": { "transports": ["websocket"] } That issue was at this link.

@AOKP Thank you for your offer. After the change in this issue, my mongo db has not went down until now. It seems to be more stable.

@TheBronx I do agree you very much that the polling requests are causing an enormous load on the server. My machine is powerful enough holding 65000+user and 140000+ posts. But the load is heavy at peak time, and if I restart nodebb, it can not even recover until the peak was passed. @administrators Any idea on this? I was obsessed with this for long... I found that the ESTABLISHED connections are too large. Does that count for this issue? No matter peak time or valley time, this number almost seems the same. user@discuss:~$ netstat -n | grep -c ESTABLISHED 14003 and the ulimit: user@discuss:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63711 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 10000 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63711 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

I use nginx as a static file server just as the wiki illustrates. And I added a log to monitor what kind of requests goes to NodeBB server. location ~ ^/(images|sounds|templates|uploads|vendor|src\/modules|nodebb\.min\.js|stylesheet\.css|admin\.css) { root /path/to/nodebb/public/; try_files $uri $uri/ @nodebb; } location / { access_log /var/log/nginx/access3.log; proxy_pass http://io_nodesss; } I found that some of requests of the static files are still going to NodeBB: "GET /src/modules/composer/preview.js?d7bd0222-d024-4aba-869d-0b088e7d5ba1 HTTP/1.1" 200 772 "GET /src/modules/composer/uploads.js?d7bd0222-d024-4aba-869d-0b088e7d5ba1 HTTP/1.1" 200 2539 "GET /src/modules/composer/drafts.js?d7bd0222-d024-4aba-869d-0b088e7d5ba1 HTTP/1.1" 200 492 And I checked that those files are not in ./src/modules, they are at ./node_modules/xxxx/static/ instead. Is there any solution to this? Don't tell me that I should copy those files to /src/modules/ manually.

Every time I restart nodebb, the site will down for about 3 minutes. At first I doubted that the nodebb may have some thing to initialize. Then I found that even if if restart nginx(not reload), this issue may also occur. During this 3 minutes, the mongodb and 3 node process eat 100% CPU and most of the memory. The 3 minutes depends on the machine, 2core-4G machine will take 3 minutes and 4core-8G machine will take 1 minutes. I wonder what was nodebb doing during that time?

@xidui said in Is there some suggested user scale or machine type for noddbb?: We have more than 100k users and more than 400k contents(mongodump make about 1G size of directory). Initially we use 1G memory machine, we find that 503 error always come. Then we upgrade the machine to 2G, some error still comes. We now have upgraded it to 4G. I wonder that is there a suggested machine for our scale? Where is community.nodebb.org hosted? Totally, we find the response speed is too slow for some pages of noddbb. We are not satisfied about it. Take a look here. I won't answer your question fully. I can say with about 50 users I was very quickly hitting 503 errors and I had to move to 1G of memory. I had some discussion with others in this thread: https://community.nodebb.org/topic/9109/503-temporarily-unavailable-due-to-excessive-load

@xidui it's not straight forward... you will have to use helpers. see here... https://github.com/psychobunny/templates.js#helpers

I'm fine with it being each. But that's really a separate issue. The app.load hook is not where we should be modifying templates.

@yariplus Thanks your tips works for me.

Good info, thanks!