The primary copy of discourse I manage is running on a 2GB droplet at digital ocean, and we’re seeing sporadic performance issues. We have about 500 users who are mostly email based, so I don’t feel it’s a load issue.
We don’t yet have the needed controls available in the admin to allow us to move to discourse hosting (which is a goal) so in the meantime, I’d love to know… what can be done to test and see if the issue is the host?
You’re in “the cloud”. 502 errors are usually the result of overloaded equipment. If the configuration is sound on your individual instance, then this could be a case of “noisy neighbors” on your host server.
This is certainly true, however in the context of the OP it does not seem to fit. The question was how to test if the host machine is the cause of the issue. The answer would be to find the cpu run time.
shrugs Guess this is what I get for being in a room with a bunch of developers. I understand the underlying hardware and how the virtual technology interacts with it, but am no programmer.
The reason “cpu runtime” is important is because it’ll begin to tell you the true state of the host, independent of what the statistics are showing for your cpu usage. There’s a lot of misconceptions about the “cloud”. One of the interesting bits I learned was that “vcore” is pretty much meaningless when you have an oversold host. Designating different vcore values to different vms can actually increase host overhead, and the lower the amount of vcores on a vm, the higher the priority the machine can have for cpu cycles.
Not sure about the zany commercials, it’s been over a decade since I had the tube plugged in.
[ ] Tree view
[ ] Shadow other users' processes
[x] Hide kernel threads
[ ] Hide userland threads
[ ] Display threads in a different color
[ ] Show custom thread names
[ ] Highlight program "basename"
[x] Highlight large numbers in memory counters
[x] Leave a margin around header
[ ] Detailed CPU time (System/IO-Wait/Hard-IRQ/Soft-IRQ/Steal/Guest)
[ ] Count CPUs from 0 instead of 1
[ ] Update process names on every refresh
For what it’s worth, this is on the host box… I had tried shortly after running the email search, and gave up before ./launcher enter app could finish… but when I tried to enter the app just now, there was no delay.
Of course, now I see there’s no htop in the docker container anyway.
I wonder though, if searching for emails is slow… in which case this thread could get split after my comment #13