- Mon Dec 28, 2015 5:11 am
#37302
So: what weighs 192 bytes and hangs around 1 minute too long? If you know the punchline, I'd really love to know!
My problem is this: while using the ESP8266WebServer there is a steady (temporary) depletion of available memory in 192-byte blocks. This can be demonstrated using the attached code, which will simply used send()/sendContent() to return a chunk of text.
When you hit the server repeatedly, available memory will just go down and down starting here (sample Serial output):
and, after a series of 50 or so GETs (I'm using simple GET -e http://192.168.1.105/inline) wind up all the way down:
After that, with no intervention at all from my part and about 1 minute after the first GET requests, memory starts being freed up again:
and eventually comes all the way back up:
Though with this toy example, losing access to about 10k of memory isn't such a big deal, in real life I'm working with a program that only leaves about 6k free when everything is up and running, so these mysterious lingering 192-byte reserved blocks wind up causing system failures when the webserver is hit repeatedly.
To get the output in the example, I've actually had to hack the ESP8266WebServer so it would immediately close connections after use (rather than wait for timeouts), but the behaviour can be seen even without this mod--so I don't think it's because of WiFiClients hanging around with open connections.
I'm guessing this stuff is either in the code that chunks sendContent data that is larger than the max packet size, or in the underlying TCP/IP stack, but these are only guesses.
If you know the underlying code, or have any pointers as to how I could get rid of this issue or minimize it (e.g. by manually closing TCP sockets or whatever it is), I would really appreciate your input.
Thanks,
Pat Deegan
My problem is this: while using the ESP8266WebServer there is a steady (temporary) depletion of available memory in 192-byte blocks. This can be demonstrated using the attached code, which will simply used send()/sendContent() to return a chunk of text.
When you hit the server repeatedly, available memory will just go down and down starting here (sample Serial output):
Code: Select all
Free heap: 33952 @ 18s.
Resp #0
Free heap: 33912 @ 18s.
Free heap: 33952 @ 18s.
Free heap: 34088 @ 18s.
Free heap: 33720 @ 18s.
Resp #1
Free heap: 33728 @ 18s.
Free heap: 33768 @ 18s.
Free heap: 33896 @ 18s.
Free heap: 33528 @ 18s.
Resp #2
Free heap: 33536 @ 18s.
Free heap: 33576 @ 18s.
Free heap: 33704 @ 18s.
Free heap: 33336 @ 19s.
Resp #3
Free heap: 33344 @ 19s.
Free heap: 33384 @ 19s.
Free heap: 33512 @ 19s
and, after a series of 50 or so GETs (I'm using simple GET -e http://192.168.1.105/inline) wind up all the way down:
Code: Select all
Resp #47
Free heap: 24896 @ 33s.
Free heap: 24936 @ 33s.
Free heap: 25064 @ 33s.
Free heap: 24696 @ 33s.
Resp #48
Free heap: 24704 @ 33s.
Free heap: 24744 @ 33s.
Free heap: 24872 @ 33s.
Free heap: 24504 @ 33s.
Resp #49
Free heap: 24512 @ 33s.
Free heap: 24552 @ 33s.
Free heap: 24680 @ 33s.
After that, with no intervention at all from my part and about 1 minute after the first GET requests, memory starts being freed up again:
Code: Select all
Free heap: 24872 @ 79s.
Free heap: 25064 @ 79s.
Free heap: 25256 @ 79s.
Free heap: 25448 @ 79s.
Free heap: 25640 @ 80s.
Free heap: 25832 @ 80s.
Free heap: 26024 @ 80s.
Free heap: 26216 @ 80s.
and eventually comes all the way back up:
Code: Select all
Free heap: 32936 @ 91s.
Free heap: 33128 @ 92s.
Free heap: 33320 @ 92s.
Free heap: 33512 @ 92s.
Free heap: 33704 @ 92s.
Free heap: 33896 @ 93s.
Free heap: 34088 @ 93s.
Free heap: 34312 @ 93s.
Though with this toy example, losing access to about 10k of memory isn't such a big deal, in real life I'm working with a program that only leaves about 6k free when everything is up and running, so these mysterious lingering 192-byte reserved blocks wind up causing system failures when the webserver is hit repeatedly.
To get the output in the example, I've actually had to hack the ESP8266WebServer so it would immediately close connections after use (rather than wait for timeouts), but the behaviour can be seen even without this mod--so I don't think it's because of WiFiClients hanging around with open connections.
I'm guessing this stuff is either in the code that chunks sendContent data that is larger than the max packet size, or in the underlying TCP/IP stack, but these are only guesses.
If you know the underlying code, or have any pointers as to how I could get rid of this issue or minimize it (e.g. by manually closing TCP sockets or whatever it is), I would really appreciate your input.
Thanks,
Pat Deegan
Attachments
Example code used to demonstrate memory depletion, based on HelloServer example.
(3.18 KiB) Downloaded 441 times
(3.18 KiB) Downloaded 441 times
