High disk IO volume after upgrading to 3.0
See original GitHub issueWe recently upgraded our containerized .net core app to 3.0. But we started to see high disk write volume in /tmp directory. We took a peek in one of the files and it looked like it was temporarily writing response data in a tmp file and unlinking after sending response. Is it by design? Would it be possible to use memory as temporary storage?
DotNet version: 3.0 Kestrel Transport: Sockets Container base: CentOS cpu cores/container: 2 memory/container: 4GB
[pid 2931533] open("/tmp/ASPNETCORE_d297fa6b-4150-4762-a06e-4f31823e2945.tmp", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = 398
[pid 2931533] write(398, "191217 38|191217 39|191217 40|19"..., 1024) = 1024
[pid 2931533] write(398, "137|191217 138|191217 139|191217"..., 1024) = 1024
[pid 2931533] write(398, "30|191217 231|191217 232|191217 "..., 1024) = 1024
[pid 2931533] write(398, "4|191217 325|191217 326|191217 3"..., 1024) = 1024
[pid 2931533] write(398, "|191217 418|191217 419|191217 42"..., 1024) = 1024
[pid 2931533] write(398, "191217 511|191217 512|191217 513"..., 1024) = 1024
[pid 2931533] write(398, "91217 623|191217 624|191217 625|"..., 1024) = 1024
[pid 2931533] write(398, "1217 744|191217 745|191217 746|1"..., 1024) = 1024
[pid 2931533] write(398, "18 786|191218 789|191218 790|191"..., 1024) = 1024
[pid 2931533] write(398, "9 853|191219 854|191219 855|1912"..., 1024) = 1024
[pid 2931533] write(398, " 981|191219 982|191219 983|19121"..., 1024) = 1024
[pid 2931533] write(398, "191218 396|191218 397|191218 398"..., 1024) = 1024
[pid 2931533] write(398, "91218 570|191218 571|191218 590|"..., 1024) = 1024
[pid 2931533] write(398, "191218 74|191218 75|191218 76|19"..., 1024) = 1024
[pid 2931533] write(398, "18 212|191218 213|191218 214|191"..., 1024) = 1024
[pid 2931533] write(398, "8 306|191218 307|191218 308|1912"..., 1024) = 1024
[pid 2931533] write(398, " 449|191218 450|191218 451|19121"..., 16384) = 16384
[pid 2951520] unlink("/tmp/ASPNETCORE_d297fa6b-4150-4762-a06e-4f31823e2945.tmp") = 0
[pid 2951520] close(398) = 0
Issue Analytics
- State:
- Created 4 years ago
- Comments:25 (16 by maintainers)
Top Results From Across the Web
Net Core 3.0 Kestrel Poor Throughput with Newtonsoft.Json
After some diagnosis, we found that the app was doing large volume disk writes that saturated I/O. It resulted in kernel panic.
Read more >High Disk I/O and CPU usage of System Process in " ...
I've a problem with high disk IO and cpu usage from the system process. With the performance monitor I can see that it...
Read more >High IO on Prime after upgrade from 3.0 to 3.1
We're seeing continuous disk reads at between 100 and 200 MB/s. and IOPS at around 2k. Is this normal behaviour?
Read more >Windows 10 docker-compose takes 100% disk usage
The process appears to take up 100% of the CPU, which is fine, but also 100%+ of the disk IO and that is...
Read more >High disk I/O activity in CentOS server
I have about 16 websites in a CentOS dedicated, and I am having some problems on high traffic hours, it seems to be...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Disabling SuppressOutputFormatterBuffering will also require enabling AllowSynchronousIO on the server. https://github.com/aspnet/Announcements/issues/342
You can configure this behavior.
There’s a tradeoff here.
In 2.2 and earlier the newtonsoft.json serializer would do synchronous writes to the output stream. For large payloads this could lead to thread starvation, and otherwise bad throughput performance.
In 3.0 and newer by default the newtonsoft.json serializer will buffer into memory (up to 32kb) and then to disk if the payload is larger than that. You can disable this behavior as shown above.
In 3.0 and newer if you use the System.Text.Json serializer, it’s fully async, so it will work efficiently for any size payload.