Multithreading example Long running time with high CPU usage

[xiaowulovenana]

HI
Sorry to bother you!

• My question is: I use the sample code in Multireading to run for a long time, which causes high CPU consumption

• The result I saw: The stack information I captured using gstack is as follows

#0 0x0000ffff8f3fdf44 in epoll_pwait () from /lib/libc.so.6 
#1 0x000000000053bd84 in mg_iotest (mgr=0xffff78000b40, ms=1000) at /home/gaojie/RSU/common/net/mongoose/mongoose.c:4500 
#2 0x000000000053bf08 in mg_mgr_poll (mgr=0xffff78000b40, ms=1000) at /home/gaojie/RSU/common/net/mongoose/mongoose.c:4604 
#3 0x0000000000513e24 in HttpServer::Start (this=0xffff78000b20) at /home/gaojie/RSU/common/net/Http/Http.cpp:200 

Environment

• mongoose version: 7.8
• Equipment system: aarch64 aarch64 GNU/Linux
• Code reference: mongoose/examples/multi-threaded/）

[scaprile]

I'm sorry, I can't imagine what you are doing wrong in your apparently C++ code that you do not post, nor guess what is going on in an environment that you don't describe.
Please correctly describe your environment and post the minimum piece of code that reproduces your issue.

[xiaowulovenana]

Sorry, the information provided is insufficient

Program running environment：Linux mogo 4.14.98+ #1 SMP PREEMPT Fri May 27 12:01:38 CST 2022 aarch64 aarch64 aarch64 GNU/Linux

Code reference: mongoose/examples/multi-threaded/）

void thread_function(void *param)
{
	struct userdata *p = (struct userdata *) param;
	// Respond, wakeup event manager
	std::string url = std::string(p->uri.ptr, p->uri.len);
	std::string body = std::string(p->body.ptr, p->body.len);
	auto it = s_handler_map.find(url);
	if (it != s_handler_map.end()){
		ReqHandler handle_func = it->second;
		handle_func(url, body, p, sendHttpRsp);
	}
	else{
		send(p->sock, RSP_ERR, strlen(RSP_ERR), 0);
	}
	close(p->sock);               // Close the connection
	free((void *) p->body.ptr);   // free body
	free((void *) p->uri.ptr);   // free uri
	free(p);                      // free userdata
}

void onHttpEvent(mg_connection *c, int ev, void *ev_data, void *fn_data)
{
	if (ev == MG_EV_HTTP_MSG) {
		mg_http_message *hm = (struct mg_http_message *) ev_data;
		userdata *data = (userdata *)calloc(1, sizeof(*data));  // worker will free it
		data->body = mg_strdup(hm->body);              // worker will free it
		data->uri = mg_strdup(hm->uri);                 // worker will free it
		data->sock = mg_mkpipe(c->mgr, _pipeEvent, c, true);  // Create pipe
		start_thread(thread_function, data);  // Start thread and pass data
	}
  	else if (ev == MG_EV_CLOSE) {
    	if (c->fn_data != NULL){
			_unlink_conns(c, (mg_connection *)c->fn_data);
		}	
  	}
}

In a nutshell, multiple url paths are registered, different processing results are returned based on different paths, and multiple clients perform http GET and post

• Ignore my code style, I just want to use multithreading to solve my concurrency scenario

• When the program runs for a few days, the CPU is high and the http get request will be blocked without return

• The above is my problem in version 7.8

1. Today, I changed the version to 7.7, and there was an error print message

4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26b77a 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26b77b 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26b77b 1 mongoose.c:4302:accept_conn    1 accept failed, errno 22
Feb 02 12:33:07 mogo Start.sh[3508]: 26b77b 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26b77b 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26b77c 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb65 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb66 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb66 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb66 1 mongoose.c:4302:accept_conn    1 accept failed, errno 22
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb66 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb67 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb67 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb67 1 mongoose.c:4302:accept_conn    1 accept failed, errno 22
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb67 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb67 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb68 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb68 1 mongoose.c:4302:accept_conn    1 accept failed, errno 22
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb68 1 mongoose.c:4419:mg_iotest      select: -1 9
Feb 02 12:33:07 mogo Start.sh[3508]: 26bb68 1 mongoose.c:4419:mg_iotest      select: -1 9

• Please help me

[scaprile]

#2018

[xiaowulovenana]

• I think I've found the problem, but I don't know why

• I annotated the code in segments and found that calling sem_open("atcontrol", O_CREAT, 0666, 1);
sem_trywait(sedmid); close(0); sem_post(sedmid); multiple times resulted in high CPU usage

• close (0) is an accidental bug in my logic. When I comment out close (0). The program runs stably and no new problems have been found。

• Thank you again for your help！

I tested with Apache 2.4.55 win64 VS17 and had the following problem

$ ./ab.exe -n 10  -k http://192.168.0.77:7999/query/static/rsu
This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.77 (be patient)...apr_pollset_poll: The timeout specified has expired (70007)

• What tools can I use for stress testing

Thank you

[scaprile]

#2018 (comment)

The example has been exercised with siege and it does not leave connections open nor shows any sign of leaking memory.