"Original" Please avoid carrying Cheng in the Go language (sudden spike in CPU)

In fact, the go language starting from the 1.6 version is very good, GC performance optimization is in place, and a variety of parallel design than a new version of C + + is indeed a lot of convenience.

There are many language packs, and the libraries are relatively stable and can be used in production environments.

This article is mainly for beginners to pay attention to a problem with Cheng run, because this problem may also be encountered in C + +, just a few code writing habits caused.

First look at a piece of code:

Func (c *wsconn) Processhandler () {for {select} {case message, OK: = <-c.processmsg://Handle Packet if!ok {break}call (message). Msghead.id, c, message. Msgcontext, int (message. Msghead.msglen))}}}

The above code is used to process a websocket binary message after the conversion to the specified processing information behavior.

But have any classmates found out what the problem is? But this code does have a problem, because when the connection is destroyed, it causes Processhandler to run Cheng, the CPU is completely full, and the whole server will explode when you have multiple connections.

First of all, Processmsg is a channel, where if the connection is closed it will close the channel at the same time, first we know that the select itself will wait for the channel, this will not consume the CPU, just like the Select function in C, itself is not consumed (improper use of the skip).

But when the channel is closed, the whole Wenwen is destroyed directly, but the break in the code causes the Select infinite loop to run, the program appears the empty running phenomenon, here the break is relative to the select, so there seems to be no problem can run up a lot of trouble.

So if there is an empty run or go language a Ctrip CPU surges, you can go to see which channel and select are not in the infinite loop.

So the correct code is:

Func (c *wsconn) Processhandler () {for {select {case message, OK: = <-c.processmsg://Handle Packet if!ok {return//This must be forced to end carrying Cheng}call (message. Msghead.id, c, message. Msgcontext, int (message. Msghead.msglen))}}}

My troubleshooting method is a way of profiling using HTTP

Here is the detailed code:

Main.go

Package Mainimport ("Log" "Runtime" "net/http"//HTTP Packet introduced _ "NET/HTTP/PPROF"//performance Analysis package introduced) Func main () {//Set run runtime in parallel. Gomaxprocs (2) logger. Setlogname ("Testserver.log")    go func () {log. Println (http. Listenandserve ("localhost:6060", Nil)} ()//here establish HTTP dedicated profiling port websock: = Knlwebsocket.create (":", "null") Websock.listen ()}

The above code is only for the reference, unable to compile, note the code inside the comment.

See the code is simple, import 2 packages:

Import ("net/http"//HTTP Packet Introduction _ "Net/http/pprof"//performance Analysis package introduced)

Then add the code to the main function:

Go func () {log. Println (http. Listenandserve ("localhost:6060", Nil)} ()//here to establish an HTTP dedicated performance analysis port

I joined a ctrip here to do performance analysis because I have my own main processing logic, so I have to use Ctrip.

After the above code is added, directly compile the launcher, Access address: http://localhost:6060/debug/pprof/, then you can perform a pleasant performance analysis

"Original" Please avoid carrying Cheng in go language (sudden CPU surge)