一次依赖注入不慎引发的一连串事故 (4)

改一下打包扔上去做一个数据收集看看。

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env WORKDIR /app # copy csproj and restore as distinct layers COPY src/*.csproj ./ RUN dotnet restore COPY . ./ # copy everything else and build RUN dotnet publish src -c Release -o /app/out # build runtime image FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 # debug # Install .NET Core SDK RUN dotnet_sdk_version=3.1.100 \ && curl -SL --output dotnet.tar.gz https://dotnetcli.azureedge.net/dotnet/Sdk/$dotnet_sdk_version/dotnet-sdk-$dotnet_sdk_version-linux-x64.tar.gz \ && dotnet_sha512='5217ae1441089a71103694be8dd5bb3437680f00e263ad28317665d819a92338a27466e7d7a2b1f6b74367dd314128db345fa8fff6e90d0c966dea7a9a43bd21' \ && echo "$dotnet_sha512 dotnet.tar.gz" | sha512sum -c - \ && rm -rf /usr/share/dotnet \ && rm -rf /usr/bin/dotnet \ && mkdir -p /usr/share/dotnet \ && tar -ozxf dotnet.tar.gz -C /usr/share/dotnet \ && rm dotnet.tar.gz \ && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet \ # Trigger first run experience by running arbitrary cmd && dotnet help RUN dotnet tool install --global dotnet-trace RUN dotnet tool install -g dotnet-dump RUN dotnet tool install --global dotnet-counters ENV PATH="$PATH:/root/.dotnet/tools" # end debug WORKDIR /app COPY --from=build-env /app/out . ENTRYPOINT ["dotnet", "Your-APP.dll"]

更新发布,等待服务正常启动之后,

使用 ab -c 300 -n 3000 '' 模拟 300 个用户同时请求,

使得程序进入上述的“假死状态”。

接着立即进入容器,执行'dotnet-trace collect -p 1' 开始收集日志。

最后拿到了一份大概 13M trace.nettrace 数据, 这个文件是 PerView 支持的格式,

在 MacOS 或者 Linux 上无法使用。

好在 dotnet-trace convert 可以将 trace.nettrace 转换成 speedscope/chromium 两种格式。

speedscope/chromium

speedscope:A fast, interactive web-based viewer for performance profiles.

chrome-devtools evaluate-performance

全新 Chrome Devtool Performance 使用指南

$dotnet-trace convert 20200606-1753-trace.nettrace.txt --format Speedscope $dotnet-trace convert 20200606-1753-trace.nettrace.txt --format chromium $speedscope 20200606-1753-trace.nettrace.speedscope.json

然后,炸鸡了。

➜ Downloads speedscope 20200606-1625.trace.speedscope.json Error: Cannot create a string longer than 0x3fffffe7 characters at Object.slice (buffer.js:652:37) at Buffer.toString (buffer.js:800:14) at main (/home/liguobao/.nvm/versions/node/v12.16.2/lib/node_modules/speedscope/bin/cli.js:69:39) at processTicksAndRejections (internal/process/task_queues.js:97:5) Usage: speedscope [filepath] If invoked with no arguments, will open a local copy of speedscope in your default browser. Once open, you can browse for a profile to import. If - is used as the filepath, will read from stdin instead. cat /path/to/profile | speedscope -

哦, Buffer.toString 炸鸡了。

看一眼 20200606-1625.trace.speedscope.json 多大?

900M。

牛逼。

那换 Chrome performance 看看。

chrome-performance

手动装载一下 20200606-1753-trace.nettrace.chromium.json 看看。

等下,20200606-1753-trace.nettrace.chromium.json 这货多大?

哦,4G。应该没事,Intel NUC 主机内存空闲 20G,吃掉 4G 完全是没有问题的。

chrome_performance_load_json

看着进度条加载,看着内存涨起来,

然后...Chrome 控制台奔溃。再见再见,原来大家彼此完全没有信任了。

唉,再来一次,把文件控制在 5M 左右看看。

最后,把 20200606-1753-trace.nettrace.chromium.json 控制在 1.5G 了,

终于可以正常加载起来了。

Chrome Performance

首先, 我们看到监控里面有一堆的线程

Chrome%20performance_threading_74

随便选一个线程看看它做撒,选择 Call Tree 之后 点点点点点。

20performance_74_call_tree

从调用栈能看到 整个线程当前状态是“PerformWaitCallback”

整个操作应该的开头应该是

Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.KestrelConnection.System.Threading.IThreadPoolWorkItem.Execute()

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpzwpj.html