etcd build-in gRPC services
Users can configure the MaxRequestSize using flag --max-request-bytes, and its default value is 1.5MB. When users configure a value greater than 10MB, then etcd generates a warning message. The existing logic on --max-request-bytes looks good to me, and we shouldn't set any hard limit on it. We just need to keep it as it's for now.
But there is a hard limit (10MB) on the maxWALEntrySize. If users configure a value > 10MB for the --max-request-bytes, then etcd can receive and process request > 10MB. But when etcd restarts later, it will fail to decode the WAL entry, see decoder.go#L88. This is definitely a bug, see also issues/14025. We can't just remove the max size limitation on the WAL entry, because etcd may run out of memory in case the WAL entry is somehow corrupted, and its size is a huge value. The proposed solution for this issue is to replace the hard code limitation 10MB with a dynamic value, which is the remaining size of the current WAL file.
Let's work with an example. Assuming the reading offset is 800 bytes, and the current WAL size is 64MB, then the max size of the current WAL entry should be (64MB - 800).
Currently the maxSendBytes is hard coded as math.MaxInt32. We may add a configuration item MaxSendMsgSize into embed.Config, and defaults to math.MaxInt32.
Users registered gRPC services
One related PR is 14066. @ptabor proposed to add an additional option, see below,
grpcAdditionalServerOptions grpc.ServerOption[]
Just as I mentioned in issuecomment-1155881593 and issuecomment-1155894742, the good side of the proposal is more flexibility; but the down side is more chance to make mistake. When users configure a different value for the max RecvMsgSize or MaxSendMsgSize via the grpcAdditionalServerOptions, then it may overwrite (or be overwritten by) the values configured by --max-request-bytes.
So I suggest not to add the grpcAdditionalServerOptions for now, until we receive valid use cases. If users want to change the max send/receive values, just use the configuration items for the etcd build-in gRPC services.
cc @ptabor @serathius @spzala @biosvs @algobardo @xiang90 @rleungx
etcd build-in gRPC services
Users can configure the MaxRequestSize using flag --max-request-bytes, and its default value is 1.5MB. When users configure a value greater than 10MB, then etcd generates a warning message. The existing logic on
--max-request-byteslooks good to me, and we shouldn't set any hard limit on it. We just need to keep it as it's for now.But there is a hard limit (10MB) on the maxWALEntrySize. If users configure a value > 10MB for the
--max-request-bytes, then etcd can receive and process request > 10MB. But when etcd restarts later, it will fail to decode the WAL entry, see decoder.go#L88. This is definitely a bug, see also issues/14025. We can't just remove the max size limitation on the WAL entry, because etcd may run out of memory in case the WAL entry is somehow corrupted, and its size is a huge value. The proposed solution for this issue is to replace the hard code limitation 10MB with a dynamic value, which is the remaining size of the current WAL file.Let's work with an example. Assuming the reading offset is 800 bytes, and the current WAL size is 64MB, then the max size of the current WAL entry should be
(64MB - 800).Currently the maxSendBytes is hard coded as
math.MaxInt32. We may add a configuration itemMaxSendMsgSizeinto embed.Config, and defaults tomath.MaxInt32.Users registered gRPC services
One related PR is 14066. @ptabor proposed to add an additional option, see below,
Just as I mentioned in issuecomment-1155881593 and issuecomment-1155894742, the good side of the proposal is more flexibility; but the down side is more chance to make mistake. When users configure a different value for the max
RecvMsgSizeorMaxSendMsgSizevia thegrpcAdditionalServerOptions, then it may overwrite (or be overwritten by) the values configured by--max-request-bytes.So I suggest not to add the
grpcAdditionalServerOptionsfor now, until we receive valid use cases. If users want to change the max send/receive values, just use the configuration items for the etcd build-in gRPC services.cc @ptabor @serathius @spzala @biosvs @algobardo @xiang90 @rleungx