Reduce socket read chunk size for queries over TCP/IP #189
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changeset reduces the socket read chunk size for queries over TCP/IP to a reasonable value of 64 KiB. PHP's
fread()uses an underlyingread()call with the given chunk size (defaults to 8 KiB) instead of the size limit given to thefread()call. In an attempt to address a race condition on Mac, I've accidentally raised this default chunk size to 2 GiB via #172/#177. This means that any socket read would temporarily consume 2 GiB of memory, even if we only read a few bytes of data. Ouch.With these changes applied, the test suite now reports a memory usage of ~84 MB instead of 8 GB(!). I've only stumbled upon this recently while addressing PHP 8.1 compatibility (#188) and trying to execute this with PHP's default
memory_limitof just 128 MiB. The good news is this didn't usually happen during normal operation, as the TCP/IP transport will only be used as a fallback if the UDP query returns a truncated message.