Timeline for How to determine the status of my server
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 23, 2016 at 11:08 | answer | added | Craig Small | timeline score: 0 | |
| Oct 13, 2016 at 20:15 | answer | added | user1133275 | timeline score: 1 | |
| Oct 13, 2016 at 19:52 | comment | added | Centimane | @Storo I also did some digging into top that was rather informative. The load average line tells the amount of processes waiting/using a CPU in the last 1/5/15 minutes. It's best for this to be less than or equal to your # cores. So you have 4 cores, and there were on average 52 processes using/waiting for a core in the last 15 minutes, so your CPU is 1300% overloaded. A CPU hardware solution would be to throw 52 cores at it. Otherwise you might want to try to reduce the time it takes for a client to respond, so that the processes don't hog the CPU for as long. | |
| Oct 13, 2016 at 19:40 | comment | added | Centimane | @Storo It would be accurate to say that more hardware would improve performance, but you'll also want to consider: what hardware is causing the bottleneck? (It looks like your CPU here, but given the background on the process you mentioned it could also be your network bandwidth, or even that the nodes are slow to respond to the server). How might the issue be resolved without purchasing more hardware? (If the issue is simply not enough CPU so be it, but something like strace might tell you more about what the process spends the most time with) | |
| Oct 13, 2016 at 18:16 | comment | added | Storo | @Centimane No, we don't have a testing environment to add 200 more nodes. Nevertheless, connecting by SSH to the server and running commands as simple as curls take many seconds to complete. Isn't this enough to say that the hardware is more than overloaded? | |
| Oct 13, 2016 at 18:01 | comment | added | Centimane | In theory adding 200 more nodes could increase workload for the process by about 28%, and your CPU usage could raise similarly, which would put you at 99% at most. Is this a production server? Do you have a test environment to try adding these extra nodes? It's really not possible to say exactly how much impact will be had on the process without knowing it intimately, but it seems that it would be pushing the hardware. | |
| Oct 13, 2016 at 17:52 | history | edited | Storo | CC BY-SA 3.0 | added 84 characters in body |
| Oct 13, 2016 at 17:47 | comment | added | Centimane | @user1133275 just because it takes up a lot of resources doesn't mean it's not optimized or running improperly. Somethings just take a lot of resources because of the nature of the tasks they perform. Without knowing more about the process itself it can't be assumed to be problematic. | |
| Oct 13, 2016 at 17:26 | comment | added | Storo | @user1133275 Since it is our product I can't link you to any documentation nor source code but I added more data related to it. | |
| Oct 13, 2016 at 17:25 | history | edited | Storo | CC BY-SA 3.0 | presence.py background |
| Oct 13, 2016 at 16:21 | comment | added | user1133275 | looks like presence.py needs optimizing or you are using it wrong. Link to the source? | |
| Oct 13, 2016 at 15:29 | review | First posts | |||
| Oct 13, 2016 at 15:48 | |||||
| Oct 13, 2016 at 15:26 | history | asked | Storo | CC BY-SA 3.0 |