weim0000 opened a new pull request, #3517:
URL: https://github.com/apache/brpc/pull/3517
### What problem does this PR solve?
When a brpc server has allocated a large amount of memory, the first request
to the /vars endpoint can cause a significant latency stall. This is because
the kernel_version bvar variable is lazily initialized on first access, and its
constructor calls popen("uname -ap") to read the kernel version.
Problem Summary:
Internally, popen() calls fork() to spawn a child process. On Linux, fork()
needs to duplicate the parent process's page tables. For a server with a large
memory footprint (e.g., tens of GBs), this can take hundreds of milliseconds or
even longer, effectively blocking the bthread that handles the /vars request.
This caused a production incident in our environment, where the service
appeared to hang when the monitoring system first scraped the /vars endpoint
after the server had been running for a while with heavy memory usage.
Changed:
Fix
Replace butil::read_command_output(oss, "uname -ap") (which shells out via
popen → fork → exec) with the POSIX uname() syscall. The uname() syscall reads
the same kernel information directly, without creating any child process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
