-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: fatal error: cannot map pages in arena address space on Windows #8491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think we need a lot more information. What is FormFile? Can you show us a complete program? Have you tried looking at a memory profile (see http://blog.golang.org/profiling-go-programs)? Labels changed: added repo-main, release-none, os-windows. |
The problem is that your address space is quite small - 32-bit windows program have only 2GB address space. So Go cannot allocate a lot of memory. If you try to run windows/amd64 (64-bit) version of Go, the limit is much high. So it should not crash as quickly. @Brad, in your opinion, how much memory should that server use under described conditions? I don't have time to investigate it properly now. Thank you. Alex |
kaixinlaoshu2008, You use r.ParseMultipartForm in your program. It uses a lot of memory, because it parses multi-part form in memory, and, if large file is part of that form, then ParseMultipartForm will use as much memory as you've allowed. You have allowed to go up to (128 << 20) bytes. So ParseMultipartForm tries to get as much memory as possible on your computer. You use windows/386 version of Go, so your total runtime heap is about 500M, so you don't have much when you are playing with 300M files. You cannot increase heap, because your OS allows for max of 2G virtual address space, and you need to fit many other things apart from Go runtime heap. I think your program behaves as expected. But I will let Brad to make that decision. He wrote this code, so he might have better suggestions. Sorry. Alex Status changed to New. |
Today I tried again on go1.4.2 linux/amd64,but got the same problem.go does't free the uploaded file's memory. |
The program is asking to parse up to 128MB of the uploaded data in memory.
On 32-bit platforms, there is only about 768MB of usable heap, it's easy to
run out of memory.
I didn't read the whole program to see if there is any other memory
problems.
|
It happens on ubuntu 14.04 x86_84/go1.4.2 linux/amd64 too.The program eats memory each time until crash when files are uploaded. My core questions is "how to free memory immediately". And my whole code is in this issue ,a go file and a html file.you can test it. |
I looked into this a little bit (with 1.3.3). I don't see quite the behavior you are. I tried uploading the same 90MB file 10+ times. The heap grows to about 500MB over the first three or four uploads and then stops. After I stop uploading, GC eventually gets back to <1MB. It takes two background cycles to get there because of the concurrent sweep. You can speed that up by calling runtime.GC(), although in your example program there really isn't a good place to do that (you'd need it inside ListenAndServe after the http.Request is dropped). We should ideally be able to handle this workload in ~256MB. I'm not entirely sure why it gets to 500MB. |
I am so sorry,my tests are not carefully enough on amd64.The program on amd64 is ok,not crash. "r.ParseMultipartForm(128 << 20)" makes the heap grows to about 511MB and then stops.If not use it, the heap upper limit is 256MB. And the memory eventually gets back to <17MB after 9 Minutes.The long time is ok? |
Now we see this issue at tip: http://build.golang.org/log/d9c532d3a1b8266fae407518d131bc872f41a617. |
@mikioh please create new issue instead. Thank you. I suspect some tests use too much memory for windows/386. Alex |
Filed #10737. |
by kaixinlaoshu2008:
The text was updated successfully, but these errors were encountered: